From brian.nisbet at heanet.ie Fri Sep 5 12:21:38 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 05 Sep 2014 11:21:38 +0100 Subject: [anti-abuse-wg] Call For RIPE 69 Agenda Items Message-ID: <54098EB2.5070800@heanet.ie> Colleagues, We're roughly two months out from RIPE69 and the next exciting Anti-Abuse Working Group Session! The meeting will take place in London from the 3rd - 7th November 2014 - http://ripe69.ripe.net The Anti-Abuse WG Session will take place on Wednesday 5th at 14:00 GMT. As always we're hoping the WG will be informative and interesting with lots of time for discussion. If you have anything you would like to see on the agenda, please contact aa-wg-chairs at ripe.net Thanks, Brian From brian.nisbet at heanet.ie Fri Sep 12 12:24:53 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 12 Sep 2014 11:24:53 +0100 Subject: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session In-Reply-To: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> References: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> Message-ID: <5412C9F5.4080207@heanet.ie> Colleagues, Here are the draft minutes from the RIPE68 AA-WG meeting in Warsaw. It would be great if people could review these and note any issues and/or action points prior to our meeting in London. As a reminder, there is still space on the agenda for the London meeting. Thanks, Brian ***************** Anti-Abuse Working Group Minutes ? RIPE 68 === A. Administrative Matters === Brian welcomed the participants to the Working Group session and introduced himself and Tobias as co-chairs. and thanked the RIPE NCC for providing support in the form of chat monitor, scribe and stenographers. The minutes from RIPE 67 and RIPE 66 were approved and there were no additions to the agenda. === B. Update === Brian asked the room if there was anything pertaining "abuse-c:" that needed to be raised. As nobody spoke up, Brian stated that it could be covered later on if needed. Brian mentioned that he had circulated some text for the working group charter. He noted that there had been some discussion but was happy to keep any discussion on the list. He invited the room to make any comments there and then if needed. There were no comments. Brian urged the participants to read the charter on the mailing list. === C. Policies === Brian stated that there were no open policies at the moment. === D1. Interactions With Other Working Groups === Regarding interactions with other working groups on policy, Brian noted that he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database Working Group Chairs, that he and Tobias would work on the data verification policy. He mentioned that he and Tobias would not have time for this soon, and therefore urged participants that, should they want to take on the task, they were welcome. === D2. Proof of identity discussions ? RIPE Policy Proposal 2007-01 === There was some discussion about the level of proof of identity that the RIPE NCC should expect. Athina Fragkouli, RIPE NCC, stated that this was also discussed in the Address Policy Working Group and there were not many concerns about how the RIPE NCC handles proof of identity. She added that the RIPE NCC is always open to changing procedures. Brian asked the room whether the RIPE NCC are doing enough, too little, or to much regarding proof of identity. He asked if there should be more trust. Jim Reid, unaffiliated, felt that things should be left as they are. He expressed that he thought it was bad to collect personal data unless there is a strong need for the data. However, he can appreciate the RIPE NCC's point and can see how it's useful in some cases, such as for law enforcement and other aspects of anti-abuse. Brian agreed that it's okay for the RIPE NCC to continue as it is. === E1. "Anti-Abuse: The View from the Messaging World" - Jerome Cudelou, M3AAWG === The presentation is available online: https://ripe68.ripe.net/presentations/373-M3AAWG.pdf Brian asked whether there are any more areas of mutual engagement that could be touched upon. Jerome responded that it would be best to become members of M3AAWG. Brian asked whether non-members of M3AAWG could contribute to M3AAWG?s documentation. Jerome responded that he didn?t think it was easy to do and that it is better to become a member. R?diger Volk, Deutsche Telekom, asked if there were documents that would explain what is expected of an abuse contact. Jerome responded that the document is under discussion. Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG, further clarified that there is the Abuse Desk Best Practises document that is now a few years old. He added that the Abuse Desk Special Interest Group has revived the document and would work on it in upcoming meetings. Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but are participating in the Hosting Special Interest Group (SIG) and the Abuse SIG so participation is possible without becoming a member. Brian asked Alex what the procedure was for participation. Alex responded that he had sent a message to Gerry Upton and received a free invitation. Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG cooperate with research institutions. She mentioned that Delft University of Technology are working on banking malware and mobile malware, and asked if M3AAWG share data with them. Jerome responded that they do share data with research institutions. Vincent noted that M3AAWG has a very open policy about inviting people to come to the European meetings and the emerging groups such as the Hosting SIG. He directed interested parties to Gerry, Jerome or himself for an invitation. Brian asked an open question to RIPE NCC members in the room whether there had been any interaction with M3AAWG since RIPE 45 in Barcelona. Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to Brussels and that the RIPE NCC did find the meeting useful for engagement with the community. ==== E2: Impact of abuse-c Bengt G?rd?n, Resilans The presentation is available online: https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf Ruediger asked whether the message to the abuse-c at Spamhaus was successful. Bengt replied that it was not, and asked if there were questions about that. Ruediger continued, adding that Spamhaus is bullying people on the Internet and that a joke he had heard is that it may be possible to send a claim of copyright or trademark infringement with the name Spamhaus and send it to .org. Bengt added that it would work. Ruediger added that the Internet community needs to make sure that things are balanced out, thanking Bengt for his presentation. Erik Bais, ATB Internet, added that they had been in the same situation with Spamhaus and it had been well-documented. Bengt responded that he had read about it. Erik continued that they had disclosed fully about their interactions with Spamhaus, who had behaved brazenly in return, finding the situation amusing and even blogging about it on their website. Erik added that Spamhaus do not care and that they have been invited to the RIPE Anti-Abuse Working Group sessions, to have a panel and discuss the proper policies, but had refused the invitation. Brian added that that the relations between the Working Group and Spamhaus were not as good as they would like, and redirected the discussion back to ?abuse-c:?. Erik stated that they transferred some of their address blocks and even after six months they still receive emails to their abuse mailbox regarding blocks that they don?t own anymore. He called for people to use the RIPE Database and asked how it is possible to make people update their information. Bengt replied that he feels the community needs to work on this issue collectively, but not necessarily in a way that results in any legislation or policy. Erik added that it?s good to remember that Spamhaus does not block mail and there is always a need for well-managed block lists. Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat contradictory to him, as they looked more like a ?suffering story? rather than a success story and he did not understand why it was being used as an example, as Bengt?s ?I told you so.? Bengt responded that maybe it is time that they give up on optimising the ?abuse-c:? for an audience that cannot be educated. Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working Group to comment on similar policies in other regions. Tobias stated that the policy about ?abuse-c:? was brought into APNIC in a different way, as well as at AFRINIC. While the implementations were different, the end result was the same - that there is an abuse contact in the Whois Database, a single space. Bengt noted that he had tried to get an abuse contact for Spamhaus and it hadn?t worked. Alex Le Heux, Kobo Inc, added that they had similar experiences with many of those blacklists. He stated that Spamhaus regularly attends M3AAWG and advised those who wanted to meet with them, to go to the Brussels meeting. He invited those with similar experiences to come to the meeting so that some sort of best practises for blacklists can be set up. Brian confirmed that a best practises document that has come out of M3AAWG already exists. === E3: Abuse-c: Next Steps for ?abuse-c:? Denis Walker and Christian Teuschel, RIPE NCC === The presentation is available online: https://ripe68.ripe.net/presentations/162-aa_wg.pdf Brian noted that time was running short, and some discussion may need to be directed to the mailing list. Ruediger asked if it was explained anywhere how ORGANISATION objects should be used. Denis responded that it was one of the big problems with the RIPE Database. Ruediger noted that there is no documentation and explanation of the data model that the RIPE NCC says that the community should be following. Denis replied, saying that no business rules were built into the software to enforce any of this, and agreeing that there are no guidelines. Ruediger argued that, if there is a data architecture that should be followed, it should be documented and agreed upon. He called for a document that explains what the architecture is. Brian asked whether this discussion would be something better suited to the Database Working Group. Peter thanked Denis and Christian for their hard work. He noted that the RIPE Policy Development Process allows early and often objections and he believes that they are at risk of going completely overboard in a variety of aspects. He stated that he thinks that the model is in the wrong direction, and he is opposed to ?salami tactics?. His interpretation of one of the slides is that there is an ORG object and the addresses hang off it, and he cannot find any document that describes it that way. The database model with which he is familiar is one built around the objects you ask for, and the information attached to the objects, in other objects. He called for changes to the model. He added that if this were moved to the Database Working Group, that would only partly help as the changes proposed from the Anti-Abuse Working Group may not be compatible with the Database Working Group point of view. Brian clarified that, if there were issues with the architecture and business rules and documentation, then it would be more appropriate for the Database Working Group to work with the RIPE NCC to get that written. Peter stated that it may be time to reconfirm the mission of the RIPE Database, adding that it should not become a ?compliance stick? for Local Internet Registries or resource holders. Christian asked Peter what he had meant by ?salami tactic? regarding the validation. Peter clarified that having a mailbox does not mean that mail is delivered or read. The next slice of salami is to validate, so that mail can be expected to be deliverable. He envisioned that, three months later, it won?t only be deliverable, but there would be a reply. Christian replied that this is what they had proposed, improving the data quality. Peter added that caution would need to be taken when regarding data quality as it is a topic for the admin-c and the resource holder. He believes that the data should be correct because that is the core mission. Via remote participation, Gilles Massen asked if, as the existing IRT objects are becoming more invisible, would it be possible to reference an IRT from the ?abuse-c:? or at least add the useful IRT features like BGP keys to the ?abuse-c:?. He stated that he would like to see relaxed constraints like a copyright-abuse-mailbox: NULL for signalling that one should not expect a reply to those sorts of messages. He also asked that IRT objects not be touched without prior discussion in the Working Group. Denis responded that the RIPE NCC understands that the IRT object is not very popular and that they have been asked to propose to the community as to how the IRT could be made more useful. He will provide feedback to the Working Group for further review. Piotr Strzy?ewski, Silesian University of Technology, referred to Bengt?s presentation, noting that some of these corporations don?t care about the ?abuse-c:? and therefore it wouldn?t be useful to establish another point of contact for them. He added that he loves the idea of national responsibility. Regarding validation, he feels there should be some policy about that. Christian responded that he thinks validation and extending the ROLE object should go through the RIPE Policy Development Process. Brian stated that he thinks it must go through that process. Christian continued, stating that extending the ROLE object is something that has come from the community. While he acknowledges that some countries have more than one national CSIRT, the implementation needs to be clear and the list of contact details for all of them should be provided. He added that the RIPE NCC is trying to work with them, in the case that the ?abuse-c:? fails. Brian asked about the origin of the request from the community. Christian replied that it hadn?t come from the mailing list, and had come from a meeting of the computer security community. Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact was a recurring point in the RIPE NCC Survey 2013?s results and therefore the RIPE NCC had started to attend security conferences. Ruediger asked Christian if the CSIRTS were happy about getting the reports, or if they were unhappy. Christian replied that they were happy. Ruediger expressed doubt and surprise that they would be happy to be ?flooded? by copyright abuse reports. He called for guidelines and information as to what kind of report people should be sending to abuse contact, and how people should be responding to these reports. Denis added that, if Ruediger wants the RIPE NCC to provide these guidelines, then the community should provide the text. Ruediger agreed with Denis that this is a task for the Working Group. Brian added that he was surprised that the CSIRTS were happy, and noted that many countries don?t have a CSIRT. He added that he would put out a call for volunteers to help work on the guidelines. Ruediger added that, without guidelines, doing validation beyond mechanics is meaningless. === E4: Introduction to Contact Databases for Abuse Handling Aaron Kaplan, nic.at === Aaron explained how they do contact lookups at csirt.at, a national CSIRT for Austria. He noted that a national CSIRT is usually just a router for abuse contact information and that there are different approaches in different countries. Aaron asked those involved with the RIPE Database to have IRT objects, ?abuse-c?, etc. as specific and up-to-date as possible as it will help those sending information to national CSIRTS for lookups. Brian asked where the information about Aaron?s presentation would be available and if he could publish it to the list. Aaron added that it is a document on Github. Brian asked if he could email the list with the URL. Aaron replied that it is part of a document that Christian Teuschel and Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a GitHub project called GitHub.com/CERTtools that is a contact cache/contact database for national CSIRTs so that they can build on the process. Brian added that it might be good to discuss this in more depth at a future RIPE Meeting. Aaron stated again that the CSIRT is just acting as a router, passing copyrights through, and the copyrights end up with network owners under their policies. However, he noted that the routing process can be optimised. There were no further questions or comments. Brian thanked Aaron for his presentation and invited the room to contribute agenda items for RIPE 69 in London. He thanked the scribe, speakers, stenographers and participants before closing the session. From ops.lists at gmail.com Fri Sep 12 12:51:33 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 12 Sep 2014 16:21:33 +0530 Subject: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session In-Reply-To: <5412C9F5.4080207@heanet.ie> References: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> <5412C9F5.4080207@heanet.ie> Message-ID: I might add that ARIN, ICANN and the IETF regularly attend M3AAWG meetings. In fact ISOC and ICANN are M3AAWG members in their own right. And I believe ARIN has a regular presence at MAAWG as well It would be trivial to have RIPE NCC attend M3AAWG meetings - the suggestion that they email Jerry Upton and ask for guest passes is correct. --srs On Fri, Sep 12, 2014 at 3:54 PM, Brian Nisbet wrote: > Colleagues, > > Here are the draft minutes from the RIPE68 AA-WG meeting in Warsaw. It would > be great if people could review these and note any issues and/or action > points prior to our meeting in London. > > As a reminder, there is still space on the agenda for the London meeting. > > Thanks, > > Brian > > ***************** > > Anti-Abuse Working Group Minutes ? RIPE 68 > > === > A. Administrative Matters > === > > Brian welcomed the participants to the Working Group session and introduced > himself and Tobias as co-chairs. and thanked the RIPE NCC for providing > support in the form of chat monitor, scribe and stenographers. > > The minutes from RIPE 67 and RIPE 66 were approved and there were no > additions to the agenda. > > === > B. Update > === > > Brian asked the room if there was anything pertaining "abuse-c:" that needed > to be raised. As nobody spoke up, Brian stated that it could be covered > later on if needed. > > Brian mentioned that he had circulated some text for the working group > charter. He noted that there had been some discussion but was happy to keep > any discussion on the list. He invited the room to make any comments there > and then if needed. > > There were no comments. > > Brian urged the participants to read the charter on the mailing list. > > === > C. Policies > === > > Brian stated that there were no open policies at the moment. > > === > D1. Interactions With Other Working Groups > === > > Regarding interactions with other working groups on policy, Brian noted that > he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database > Working Group Chairs, that he and Tobias would work on the data verification > policy. He mentioned that he and Tobias would not have time for this soon, > and therefore urged participants that, should they want to take on the task, > they were welcome. > > === > D2. Proof of identity discussions ? RIPE Policy Proposal 2007-01 > === > > There was some discussion about the level of proof of identity that the RIPE > NCC should expect. > > Athina Fragkouli, RIPE NCC, stated that this was also discussed in the > Address Policy Working Group and there were not many concerns about how the > RIPE NCC handles proof of identity. She added that the RIPE NCC is always > open to changing procedures. > > Brian asked the room whether the RIPE NCC are doing enough, too little, or > to much regarding proof of identity. He asked if there should be more trust. > > Jim Reid, unaffiliated, felt that things should be left as they are. He > expressed that he thought it was bad to collect personal data unless there > is a strong need for the data. However, he can appreciate the RIPE NCC's > point and can see how it's useful in some cases, such as for law enforcement > and other aspects of anti-abuse. > > Brian agreed that it's okay for the RIPE NCC to continue as it is. > > === > E1. "Anti-Abuse: The View from the Messaging World" - Jerome Cudelou, M3AAWG > === > > The presentation is available online: > https://ripe68.ripe.net/presentations/373-M3AAWG.pdf > > Brian asked whether there are any more areas of mutual engagement that could > be touched upon. > > Jerome responded that it would be best to become members of M3AAWG. > > Brian asked whether non-members of M3AAWG could contribute to M3AAWG?s > documentation. > > Jerome responded that he didn?t think it was easy to do and that it is > better to become a member. > > R?diger Volk, Deutsche Telekom, asked if there were documents that would > explain what is expected of an abuse contact. > > Jerome responded that the document is under discussion. > > Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG, > further clarified that there is the Abuse Desk Best Practises document that > is now a few years old. He added that the Abuse Desk Special Interest Group > has revived the document and would work on it in upcoming meetings. > > Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but > are participating in the Hosting Special Interest Group (SIG) and the Abuse > SIG so participation is possible without becoming a member. > > Brian asked Alex what the procedure was for participation. > > Alex responded that he had sent a message to Gerry Upton and received a free > invitation. > > Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG > cooperate with research institutions. She mentioned that Delft University of > Technology are working on banking malware and mobile malware, and asked if > M3AAWG share data with them. > > Jerome responded that they do share data with research institutions. > > Vincent noted that M3AAWG has a very open policy about inviting people to > come to the European meetings and the emerging groups such as the Hosting > SIG. He directed interested parties to Gerry, Jerome or himself for an > invitation. > > Brian asked an open question to RIPE NCC members in the room whether there > had been any interaction with M3AAWG since RIPE 45 in Barcelona. > > Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to > Brussels and that the RIPE NCC did find the meeting useful for engagement > with the community. > > ==== > E2: Impact of abuse-c > Bengt G?rd?n, Resilans > > The presentation is available online: > https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf > > Ruediger asked whether the message to the abuse-c at Spamhaus was > successful. > > Bengt replied that it was not, and asked if there were questions about that. > > Ruediger continued, adding that Spamhaus is bullying people on the Internet > and that a joke he had heard is that it may be possible to send a claim of > copyright or trademark infringement with the name Spamhaus and send it to > .org. > > Bengt added that it would work. > > Ruediger added that the Internet community needs to make sure that things > are balanced out, thanking Bengt for his presentation. > > Erik Bais, ATB Internet, added that they had been in the same situation with > Spamhaus and it had been well-documented. > > Bengt responded that he had read about it. > > Erik continued that they had disclosed fully about their interactions with > Spamhaus, who had behaved brazenly in return, finding the situation amusing > and even blogging about it on their website. Erik added that Spamhaus do not > care and that they have been invited to the RIPE Anti-Abuse Working Group > sessions, to have a panel and discuss the proper policies, but had refused > the invitation. > > Brian added that that the relations between the Working Group and Spamhaus > were not as good as they would like, and redirected the discussion back to > ?abuse-c:?. > > Erik stated that they transferred some of their address blocks and even > after six months they still receive emails to their abuse mailbox regarding > blocks that they don?t own anymore. He called for people to use the RIPE > Database and asked how it is possible to make people update their > information. > > Bengt replied that he feels the community needs to work on this issue > collectively, but not necessarily in a way that results in any legislation > or policy. > > Erik added that it?s good to remember that Spamhaus does not block mail and > there is always a need for well-managed block lists. > > Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat > contradictory to him, as they looked more like a ?suffering story? rather > than a success story and he did not understand why it was being used as an > example, as Bengt?s ?I told you so.? > > Bengt responded that maybe it is time that they give up on optimising the > ?abuse-c:? for an audience that cannot be educated. > > Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working > Group to comment on similar policies in other regions. > > Tobias stated that the policy about ?abuse-c:? was brought into APNIC in a > different way, as well as at AFRINIC. While the implementations were > different, the end result was the same - that there is an abuse contact in > the Whois Database, a single space. > > Bengt noted that he had tried to get an abuse contact for Spamhaus and it > hadn?t worked. > > Alex Le Heux, Kobo Inc, added that they had similar experiences with many of > those blacklists. He stated that Spamhaus regularly attends M3AAWG and > advised those who wanted to meet with them, to go to the Brussels meeting. > He invited those with similar experiences to come to the meeting so that > some sort of best practises for blacklists can be set up. > > Brian confirmed that a best practises document that has come out of M3AAWG > already exists. > > === > E3: Abuse-c: Next Steps for ?abuse-c:? > Denis Walker and Christian Teuschel, RIPE NCC > === > > The presentation is available online: > https://ripe68.ripe.net/presentations/162-aa_wg.pdf > > Brian noted that time was running short, and some discussion may need to be > directed to the mailing list. > > Ruediger asked if it was explained anywhere how ORGANISATION objects should > be used. > > Denis responded that it was one of the big problems with the RIPE Database. > > Ruediger noted that there is no documentation and explanation of the data > model that the RIPE NCC says that the community should be following. > > Denis replied, saying that no business rules were built into the software to > enforce any of this, and agreeing that there are no guidelines. > > Ruediger argued that, if there is a data architecture that should be > followed, it should be documented and agreed upon. He called for a document > that explains what the architecture is. > > Brian asked whether this discussion would be something better suited to the > Database Working Group. > > Peter thanked Denis and Christian for their hard work. He noted that the > RIPE Policy Development Process allows early and often objections and he > believes that they are at risk of going completely overboard in a variety of > aspects. He stated that he thinks that the model is in the wrong direction, > and he is opposed to ?salami tactics?. His interpretation of one of the > slides is that there is an ORG object and the addresses hang off it, and he > cannot find any document that describes it that way. The database model with > which he is familiar is one built around the objects you ask for, and the > information attached to the objects, in other objects. He called for changes > to the model. He added that if this were moved to the Database Working > Group, that would only partly help as the changes proposed from the > Anti-Abuse Working Group may not be compatible with the Database Working > Group point of view. > > Brian clarified that, if there were issues with the architecture and > business rules and documentation, then it would be more appropriate for the > Database Working Group to work with the RIPE NCC to get that written. > > Peter stated that it may be time to reconfirm the mission of the RIPE > Database, adding that it should not become a ?compliance stick? for Local > Internet Registries or resource holders. > > Christian asked Peter what he had meant by ?salami tactic? regarding the > validation. > > Peter clarified that having a mailbox does not mean that mail is delivered > or read. The next slice of salami is to validate, so that mail can be > expected to be deliverable. He envisioned that, three months later, it > won?t only be deliverable, but there would be a reply. > > Christian replied that this is what they had proposed, improving the data > quality. > > Peter added that caution would need to be taken when regarding data quality > as it is a topic for the admin-c and the resource holder. He believes that > the data should be correct because that is the core mission. > > Via remote participation, Gilles Massen asked if, as the existing IRT > objects are becoming more invisible, would it be possible to reference an > IRT from the ?abuse-c:? or at least add the useful IRT features like BGP > keys to the ?abuse-c:?. He stated that he would like to see relaxed > constraints like a copyright-abuse-mailbox: NULL for signalling that one > should not expect a reply to those sorts of messages. He also asked that IRT > objects not be touched without prior discussion in the Working Group. > > Denis responded that the RIPE NCC understands that the IRT object is not > very popular and that they have been asked to propose to the community as to > how the IRT could be made more useful. He will provide feedback to the > Working Group for further review. > > Piotr Strzy?ewski, Silesian University of Technology, referred to Bengt?s > presentation, noting that some of these corporations don?t care about the > ?abuse-c:? and therefore it wouldn?t be useful to establish another point of > contact for them. He added that he loves the idea of national > responsibility. Regarding validation, he feels there should be some policy > about that. > > Christian responded that he thinks validation and extending the ROLE object > should go through the RIPE Policy Development Process. > > Brian stated that he thinks it must go through that process. > > Christian continued, stating that extending the ROLE object is something > that has come from the community. While he acknowledges that some countries > have more than one national CSIRT, the implementation needs to be clear and > the list of contact details for all of them should be provided. He added > that the RIPE NCC is trying to work with them, in the case that the > ?abuse-c:? fails. > > Brian asked about the origin of the request from the community. > > Christian replied that it hadn?t come from the mailing list, and had come > from a meeting of the computer security community. > > Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact > was a recurring point in the RIPE NCC Survey 2013?s results and therefore > the RIPE NCC had started to attend security conferences. > > Ruediger asked Christian if the CSIRTS were happy about getting the reports, > or if they were unhappy. > > Christian replied that they were happy. > > Ruediger expressed doubt and surprise that they would be happy to be > ?flooded? by copyright abuse reports. He called for guidelines and > information as to what kind of report people should be sending to abuse > contact, and how people should be responding to these reports. > > Denis added that, if Ruediger wants the RIPE NCC to provide these > guidelines, then the community should provide the text. > > Ruediger agreed with Denis that this is a task for the Working Group. > > Brian added that he was surprised that the CSIRTS were happy, and noted that > many countries don?t have a CSIRT. He added that he would put out a call for > volunteers to help work on the guidelines. > > Ruediger added that, without guidelines, doing validation beyond mechanics > is meaningless. > > === > E4: Introduction to Contact Databases for Abuse Handling > Aaron Kaplan, nic.at > === > > Aaron explained how they do contact lookups at csirt.at, a national CSIRT > for Austria. He noted that a national CSIRT is usually just a router for > abuse contact information and that there are different approaches in > different countries. Aaron asked those involved with the RIPE Database to > have IRT objects, ?abuse-c?, etc. as specific and up-to-date as possible as > it will help those sending information to national CSIRTS for lookups. > > Brian asked where the information about Aaron?s presentation would be > available and if he could publish it to the list. > > Aaron added that it is a document on Github. > > Brian asked if he could email the list with the URL. > > Aaron replied that it is part of a document that Christian Teuschel and > Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a > GitHub project called GitHub.com/CERTtools that is a contact cache/contact > database for national CSIRTs so that they can build on the process. > > Brian added that it might be good to discuss this in more depth at a future > RIPE Meeting. > > Aaron stated again that the CSIRT is just acting as a router, passing > copyrights through, and the copyrights end up with network owners under > their policies. However, he noted that the routing process can be optimised. > > There were no further questions or comments. > > Brian thanked Aaron for his presentation and invited the room to contribute > agenda items for RIPE 69 in London. He thanked the scribe, speakers, > stenographers and participants before closing the session. > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From md at Linux.IT Fri Sep 12 16:14:07 2014 From: md at Linux.IT (Marco d'Itri) Date: Fri, 12 Sep 2014 16:14:07 +0200 Subject: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session In-Reply-To: References: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> <5412C9F5.4080207@heanet.ie> Message-ID: <20140912141407.GA19504@bongo.bofh.it> On Sep 12, Suresh Ramasubramanian wrote: > It would be trivial to have RIPE NCC attend M3AAWG meetings - the > suggestion that they email Jerry Upton and ask for guest passes is > correct. Indeed a person from RIPE NCC attended the Brussels M3AAWG meeting. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: Digital signature URL: From ops.lists at gmail.com Fri Sep 12 18:17:01 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 12 Sep 2014 21:47:01 +0530 Subject: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session In-Reply-To: <20140912141407.GA19504@bongo.bofh.it> References: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> <5412C9F5.4080207@heanet.ie> <20140912141407.GA19504@bongo.bofh.it> Message-ID: Is that so? Well they are welcome again I would assume, and even more welcome if they join as members. If that helps address some of the issues this group keeps raising (several that might be viewpoints your own colleagues from isp security and abuse teams rather than routing and dns teams share) then I would certainly be glad Oh yes, you might also find that spamhaus aren't a bunch of ogres. On 12-Sep-2014 7:45 pm, "Marco d'Itri" wrote: > On Sep 12, Suresh Ramasubramanian wrote: > > > It would be trivial to have RIPE NCC attend M3AAWG meetings - the > > suggestion that they email Jerry Upton and ask for guest passes is > > correct. > Indeed a person from RIPE NCC attended the Brussels M3AAWG meeting. > > -- > ciao, > Marco > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry1upton at aol.com Sat Sep 13 18:26:19 2014 From: jerry1upton at aol.com (Jerry Upton) Date: Sat, 13 Sep 2014 12:26:19 -0400 Subject: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session In-Reply-To: References: <007E0A05-B1D6-45BD-A05D-1ABC4702AB09@ripe.net> <5412C9F5.4080207@heanet.ie> Message-ID: <8D19D8695B10BBA-C98-63C76@webmail-vm029.sysops.aol.com> All, RIPE NCC members are welcome to attend our M3AAWG meeting as nonmember guests. Our upcoming meeting are listed at http://www.m3aawg.org/events/upcoming_meetings Please send all requests to me. Regards, Jerry Upton Executive Director M3AAWG ? Messaging, Malware, Mobile -----Original Message----- From: Suresh Ramasubramanian To: Brian Nisbet Cc: anti-abuse-wg Sent: Fri, Sep 12, 2014 5:52 am Subject: Re: [anti-abuse-wg] RIPE 68 Minutes for the Anti-Abuse Working Group Session I might add that ARIN, ICANN and the IETF regularly attend M3AAWG meetings. In fact ISOC and ICANN are M3AAWG members in their own right. And I believe ARIN has a regular presence at MAAWG as well It would be trivial to have RIPE NCC attend M3AAWG meetings - the suggestion that they email Jerry Upton and ask for guest passes is correct. --srs On Fri, Sep 12, 2014 at 3:54 PM, Brian Nisbet wrote: > Colleagues, > > Here are the draft minutes from the RIPE68 AA-WG meeting in Warsaw. It would > be great if people could review these and note any issues and/or action > points prior to our meeting in London. > > As a reminder, there is still space on the agenda for the London meeting. > > Thanks, > > Brian > > ***************** > > Anti-Abuse Working Group Minutes ? RIPE 68 > > === > A. Administrative Matters > === > > Brian welcomed the participants to the Working Group session and introduced > himself and Tobias as co-chairs. and thanked the RIPE NCC for providing > support in the form of chat monitor, scribe and stenographers. > > The minutes from RIPE 67 and RIPE 66 were approved and there were no > additions to the agenda. > > === > B. Update > === > > Brian asked the room if there was anything pertaining "abuse-c:" that needed > to be raised. As nobody spoke up, Brian stated that it could be covered > later on if needed. > > Brian mentioned that he had circulated some text for the working group > charter. He noted that there had been some discussion but was happy to keep > any discussion on the list. He invited the room to make any comments there > and then if needed. > > There were no comments. > > Brian urged the participants to read the charter on the mailing list. > > === > C. Policies > === > > Brian stated that there were no open policies at the moment. > > === > D1. Interactions With Other Working Groups > === > > Regarding interactions with other working groups on policy, Brian noted that > he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database > Working Group Chairs, that he and Tobias would work on the data verification > policy. He mentioned that he and Tobias would not have time for this soon, > and therefore urged participants that, should they want to take on the task, > they were welcome. > > === > D2. Proof of identity discussions ? RIPE Policy Proposal 2007-01 > === > > There was some discussion about the level of proof of identity that the RIPE > NCC should expect. > > Athina Fragkouli, RIPE NCC, stated that this was also discussed in the > Address Policy Working Group and there were not many concerns about how the > RIPE NCC handles proof of identity. She added that the RIPE NCC is always > open to changing procedures. > > Brian asked the room whether the RIPE NCC are doing enough, too little, or > to much regarding proof of identity. He asked if there should be more trust. > > Jim Reid, unaffiliated, felt that things should be left as they are. He > expressed that he thought it was bad to collect personal data unless there > is a strong need for the data. However, he can appreciate the RIPE NCC's > point and can see how it's useful in some cases, such as for law enforcement > and other aspects of anti-abuse. > > Brian agreed that it's okay for the RIPE NCC to continue as it is. > > === > E1. "Anti-Abuse: The View from the Messaging World" - Jerome Cudelou, M3AAWG > === > > The presentation is available online: > https://ripe68.ripe.net/presentations/373-M3AAWG.pdf > > Brian asked whether there are any more areas of mutual engagement that could > be touched upon. > > Jerome responded that it would be best to become members of M3AAWG. > > Brian asked whether non-members of M3AAWG could contribute to M3AAWG?s > documentation. > > Jerome responded that he didn?t think it was easy to do and that it is > better to become a member. > > R?diger Volk, Deutsche Telekom, asked if there were documents that would > explain what is expected of an abuse contact. > > Jerome responded that the document is under discussion. > > Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG, > further clarified that there is the Abuse Desk Best Practises document that > is now a few years old. He added that the Abuse Desk Special Interest Group > has revived the document and would work on it in upcoming meetings. > > Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but > are participating in the Hosting Special Interest Group (SIG) and the Abuse > SIG so participation is possible without becoming a member. > > Brian asked Alex what the procedure was for participation. > > Alex responded that he had sent a message to Gerry Upton and received a free > invitation. > > Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG > cooperate with research institutions. She mentioned that Delft University of > Technology are working on banking malware and mobile malware, and asked if > M3AAWG share data with them. > > Jerome responded that they do share data with research institutions. > > Vincent noted that M3AAWG has a very open policy about inviting people to > come to the European meetings and the emerging groups such as the Hosting > SIG. He directed interested parties to Gerry, Jerome or himself for an > invitation. > > Brian asked an open question to RIPE NCC members in the room whether there > had been any interaction with M3AAWG since RIPE 45 in Barcelona. > > Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to > Brussels and that the RIPE NCC did find the meeting useful for engagement > with the community. > > ==== > E2: Impact of abuse-c > Bengt G?rd?n, Resilans > > The presentation is available online: > https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf > > Ruediger asked whether the message to the abuse-c at Spamhaus was > successful. > > Bengt replied that it was not, and asked if there were questions about that. > > Ruediger continued, adding that Spamhaus is bullying people on the Internet > and that a joke he had heard is that it may be possible to send a claim of > copyright or trademark infringement with the name Spamhaus and send it to > .org. > > Bengt added that it would work. > > Ruediger added that the Internet community needs to make sure that things > are balanced out, thanking Bengt for his presentation. > > Erik Bais, ATB Internet, added that they had been in the same situation with > Spamhaus and it had been well-documented. > > Bengt responded that he had read about it. > > Erik continued that they had disclosed fully about their interactions with > Spamhaus, who had behaved brazenly in return, finding the situation amusing > and even blogging about it on their website. Erik added that Spamhaus do not > care and that they have been invited to the RIPE Anti-Abuse Working Group > sessions, to have a panel and discuss the proper policies, but had refused > the invitation. > > Brian added that that the relations between the Working Group and Spamhaus > were not as good as they would like, and redirected the discussion back to > ?abuse-c:?. > > Erik stated that they transferred some of their address blocks and even > after six months they still receive emails to their abuse mailbox regarding > blocks that they don?t own anymore. He called for people to use the RIPE > Database and asked how it is possible to make people update their > information. > > Bengt replied that he feels the community needs to work on this issue > collectively, but not necessarily in a way that results in any legislation > or policy. > > Erik added that it?s good to remember that Spamhaus does not block mail and > there is always a need for well-managed block lists. > > Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat > contradictory to him, as they looked more like a ?suffering story? rather > than a success story and he did not understand why it was being used as an > example, as Bengt?s ?I told you so.? > > Bengt responded that maybe it is time that they give up on optimising the > ?abuse-c:? for an audience that cannot be educated. > > Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working > Group to comment on similar policies in other regions. > > Tobias stated that the policy about ?abuse-c:? was brought into APNIC in a > different way, as well as at AFRINIC. While the implementations were > different, the end result was the same - that there is an abuse contact in > the Whois Database, a single space. > > Bengt noted that he had tried to get an abuse contact for Spamhaus and it > hadn?t worked. > > Alex Le Heux, Kobo Inc, added that they had similar experiences with many of > those blacklists. He stated that Spamhaus regularly attends M3AAWG and > advised those who wanted to meet with them, to go to the Brussels meeting. > He invited those with similar experiences to come to the meeting so that > some sort of best practises for blacklists can be set up. > > Brian confirmed that a best practises document that has come out of M3AAWG > already exists. > > === > E3: Abuse-c: Next Steps for ?abuse-c:? > Denis Walker and Christian Teuschel, RIPE NCC > === > > The presentation is available online: > https://ripe68.ripe.net/presentations/162-aa_wg.pdf > > Brian noted that time was running short, and some discussion may need to be > directed to the mailing list. > > Ruediger asked if it was explained anywhere how ORGANISATION objects should > be used. > > Denis responded that it was one of the big problems with the RIPE Database. > > Ruediger noted that there is no documentation and explanation of the data > model that the RIPE NCC says that the community should be following. > > Denis replied, saying that no business rules were built into the software to > enforce any of this, and agreeing that there are no guidelines. > > Ruediger argued that, if there is a data architecture that should be > followed, it should be documented and agreed upon. He called for a document > that explains what the architecture is. > > Brian asked whether this discussion would be something better suited to the > Database Working Group. > > Peter thanked Denis and Christian for their hard work. He noted that the > RIPE Policy Development Process allows early and often objections and he > believes that they are at risk of going completely overboard in a variety of > aspects. He stated that he thinks that the model is in the wrong direction, > and he is opposed to ?salami tactics?. His interpretation of one of the > slides is that there is an ORG object and the addresses hang off it, and he > cannot find any document that describes it that way. The database model with > which he is familiar is one built around the objects you ask for, and the > information attached to the objects, in other objects. He called for changes > to the model. He added that if this were moved to the Database Working > Group, that would only partly help as the changes proposed from the > Anti-Abuse Working Group may not be compatible with the Database Working > Group point of view. > > Brian clarified that, if there were issues with the architecture and > business rules and documentation, then it would be more appropriate for the > Database Working Group to work with the RIPE NCC to get that written. > > Peter stated that it may be time to reconfirm the mission of the RIPE > Database, adding that it should not become a ?compliance stick? for Local > Internet Registries or resource holders. > > Christian asked Peter what he had meant by ?salami tactic? regarding the > validation. > > Peter clarified that having a mailbox does not mean that mail is delivered > or read. The next slice of salami is to validate, so that mail can be > expected to be deliverable. He envisioned that, three months later, it > won?t only be deliverable, but there would be a reply. > > Christian replied that this is what they had proposed, improving the data > quality. > > Peter added that caution would need to be taken when regarding data quality > as it is a topic for the admin-c and the resource holder. He believes that > the data should be correct because that is the core mission. > > Via remote participation, Gilles Massen asked if, as the existing IRT > objects are becoming more invisible, would it be possible to reference an > IRT from the ?abuse-c:? or at least add the useful IRT features like BGP > keys to the ?abuse-c:?. He stated that he would like to see relaxed > constraints like a copyright-abuse-mailbox: NULL for signalling that one > should not expect a reply to those sorts of messages. He also asked that IRT > objects not be touched without prior discussion in the Working Group. > > Denis responded that the RIPE NCC understands that the IRT object is not > very popular and that they have been asked to propose to the community as to > how the IRT could be made more useful. He will provide feedback to the > Working Group for further review. > > Piotr Strzy?ewski, Silesian University of Technology, referred to Bengt?s > presentation, noting that some of these corporations don?t care about the > ?abuse-c:? and therefore it wouldn?t be useful to establish another point of > contact for them. He added that he loves the idea of national > responsibility. Regarding validation, he feels there should be some policy > about that. > > Christian responded that he thinks validation and extending the ROLE object > should go through the RIPE Policy Development Process. > > Brian stated that he thinks it must go through that process. > > Christian continued, stating that extending the ROLE object is something > that has come from the community. While he acknowledges that some countries > have more than one national CSIRT, the implementation needs to be clear and > the list of contact details for all of them should be provided. He added > that the RIPE NCC is trying to work with them, in the case that the > ?abuse-c:? fails. > > Brian asked about the origin of the request from the community. > > Christian replied that it hadn?t come from the mailing list, and had come > from a meeting of the computer security community. > > Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact > was a recurring point in the RIPE NCC Survey 2013?s results and therefore > the RIPE NCC had started to attend security conferences. > > Ruediger asked Christian if the CSIRTS were happy about getting the reports, > or if they were unhappy. > > Christian replied that they were happy. > > Ruediger expressed doubt and surprise that they would be happy to be > ?flooded? by copyright abuse reports. He called for guidelines and > information as to what kind of report people should be sending to abuse > contact, and how people should be responding to these reports. > > Denis added that, if Ruediger wants the RIPE NCC to provide these > guidelines, then the community should provide the text. > > Ruediger agreed with Denis that this is a task for the Working Group. > > Brian added that he was surprised that the CSIRTS were happy, and noted that > many countries don?t have a CSIRT. He added that he would put out a call for > volunteers to help work on the guidelines. > > Ruediger added that, without guidelines, doing validation beyond mechanics > is meaningless. > > === > E4: Introduction to Contact Databases for Abuse Handling > Aaron Kaplan, nic.at > === > > Aaron explained how they do contact lookups at csirt.at, a national CSIRT > for Austria. He noted that a national CSIRT is usually just a router for > abuse contact information and that there are different approaches in > different countries. Aaron asked those involved with the RIPE Database to > have IRT objects, ?abuse-c?, etc. as specific and up-to-date as possible as > it will help those sending information to national CSIRTS for lookups. > > Brian asked where the information about Aaron?s presentation would be > available and if he could publish it to the list. > > Aaron added that it is a document on Github. > > Brian asked if he could email the list with the URL. > > Aaron replied that it is part of a document that Christian Teuschel and > Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a > GitHub project called GitHub.com/CERTtools that is a contact cache/contact > database for national CSIRTs so that they can build on the process. > > Brian added that it might be good to discuss this in more depth at a future > RIPE Meeting. > > Aaron stated again that the CSIRT is just acting as a router, passing > copyrights through, and the copyrights end up with network owners under > their policies. However, he noted that the routing process can be optimised. > > There were no further questions or comments. > > Brian thanked Aaron for his presentation and invited the room to contribute > agenda items for RIPE 69 in London. He thanked the scribe, speakers, > stenographers and participants before closing the session. > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.nisbet at heanet.ie Fri Sep 26 11:23:32 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 26 Sep 2014 10:23:32 +0100 Subject: [anti-abuse-wg] Appointment & Removal of Working Group Chairs Message-ID: <54253094.7070309@heanet.ie> Colleagues, As you may have seen on other mailing lists all of the RIPE WG Chairs have been asked to open the discussion with their relevant working groups regarding an agreed set of procedures for the appointment and potential removal of working group chairs, or certainly allowing for their replacement. This is up to each WG to discuss and reach consensus on and is far from set in stone. Tobias & I would like to present the text below as a starting point for this discussion and we welcome your thoughts. While this conversation may be done and dusted on the mailing list before we get to RIPE 69, we will set aside some time at the meeting to discuss it. ****************************** Note on Language: Throughout this document the word Chair shall be used for both Chairs and Co-Chairs. ** Introduction: This document aims to provide outline procedures to deal with the tenure of RIPE Working Group Chairs. It applies to all RIPE Working Groups. ** WG Chair Term: The normal term for a WG Chair is three years, after which the WG Chair must resign. A WG Chair may stand for re-selection after resignation. A WG Chair may resign voluntarily at any time. ** Selection of a WG Chair: WG Chair vacancies, along with a call for candidates, should be announced on the WG mailing list at least one month in advance of the date upon which the selection will be held. The announcement should set a closing date for candidates. A WG may request that a WG Chair vacancy be opened so long as the addition of a new Chair would not cause the number of Chairs of that WG to exceed the maximum number specified in this document. WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically present at the WG session is eligible to participate in the selection process. The candidate does not need to be physically present at the WG session. If possible the Chair should be elected by acclamation by the WG or by consensus after discussion. If the result is unclear, then a secret ballot should be held. In the case of a ballot, votes will be counted by RIPE NCC Staff and/or Chairs of other WGs. The result will be determined by simple majority. ** Removal of a WG Chair: A WG Chair may be unable to fulfil their duties as described in this document or otherwise fail to serve the WG and the community. With the endorsement of a significant share of the WG, a vote of no confidence may be initiated. Before a vote of no confidence is taken, due effort should be made to address the issue(s) leading to the vote. The right of reply must be given to all parties involved in the procedure. If this effort fails to resolve the issue, the vote may proceed. The vote must be requested on the WG mailing list at least one week in advance of the WG Session at a RIPE meeting and should take place during the WG session. Anyone physically present at the WG session may take part in the vote. The vote should be conducted by secret ballot and votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The result will be determined by simple majority. If the vote of no confidence in a WG Chair is passed, the seat is vacated and the WG Chair is not eligible for stand for re-selection. ** No Chair: If a working group is left with no Chair, e.g. due to the resignation or removal of the sole WG Chair, then the WG may elect an interim WG Chair according to the selection procedures specified above, but with candidates nominated at the WG session. An interim WG Chair must resign at the next WG session, but may stand for re-selection. ** Staggered Introduction: For the purposes of staggering the introduction of this policy, in the case where all co-Chairs of a WG have served for more than the standard WG Chair term limit, an optional waiver is given to these WGs to allow them to schedule the automatic resignations of their Chairs over the two RIPE meetings immediately following the adoption of this policy. If the WG decides to avail of this waiver, it is the responsibility of the WG to decide in what order its co-Chairs should stand down. From dhc at dcrocker.net Fri Sep 26 15:42:20 2014 From: dhc at dcrocker.net (Dave Crocker) Date: Fri, 26 Sep 2014 06:42:20 -0700 Subject: [anti-abuse-wg] Appointment & Removal of Working Group Chairs In-Reply-To: <54253094.7070309@heanet.ie> References: <54253094.7070309@heanet.ie> Message-ID: <54256D3C.9050708@dcrocker.net> On 9/26/2014 2:23 AM, Brian Nisbet wrote: > Tobias & I would like to present the text below as a starting point for > this discussion These are always fun exercises... > Note on Language: Throughout this document the word Chair shall be used > for both Chairs and Co-Chairs. > > ** Introduction: > > This document aims to provide outline procedures to deal with the tenure > of RIPE Working Group Chairs. It applies to all RIPE Working Groups. This document outlines procedures dealing with the tenure... > ** WG Chair Term: > > The normal term for a WG Chair is three years, after which the WG Chair > must resign. A WG Chair may stand for re-selection after resignation. A > WG Chair may resign voluntarily at any time. As phrased, this means that there is a gap between resignation and filling the spot with the replacement chair. And if the resignation is 'forced' it isn't really a resignation; it's just the end of their term. Perhaps: The term of a WG Chair is three years. A current chair may stand for re-selection at the end of their term. A WG Chair may resign voluntarily at any time. > ** Selection of a WG Chair: > > WG Chair vacancies, along with a call for candidates, should be should -> must Seems essential to make the minimum announcement time mandatory. > announced on the WG mailing list at least one month in advance of the > date upon which the selection will be held. The announcement should set > a closing date for candidates. A WG may request that a WG Chair vacancy a WG Chair vacancy -> an additional WG Chair position > be opened so long as the addition of a new Chair would not cause the > number of Chairs of that WG to exceed the maximum number specified in > this document. I didn't see where that maximum was specified. > > WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically > present at the WG session is eligible to participate in the selection > process. The candidate does not need to be physically present at the WG > session. > > If possible the Chair should be elected by acclamation by the WG or by > consensus after discussion. If the result is unclear, then a secret > ballot should be held. In the case of a ballot, votes will be counted by > RIPE NCC Staff and/or Chairs of other WGs. The result will be determined > by simple majority. > > ** Removal of a WG Chair: > > A WG Chair may be unable to fulfil their duties as described in this > document or otherwise fail to serve the WG and the community. With the > endorsement of a significant share of the WG, a vote of no confidence > may be initiated. > > Before a vote of no confidence is taken, due effort should be made to > address the issue(s) leading to the vote. The right of reply must be > given to all parties involved in the procedure. If this effort fails to > resolve the issue, the vote may proceed. > > The vote must be requested on the WG mailing list at least one week in > advance of the WG Session at a RIPE meeting and should take place during > the WG session. Anyone physically present at the WG session may take This obviously allows a form of ballot-box stuffing, by permitting votes from people who have not been involved in the wg up to that point. I have no idea how to prevent this, however. In addition, it can be argued that anyone garnering enough ire to motivate the ballot-stuffing effort probably is causing serious problems. The counter to that is that they might be standing up to efforts to coerce the wg... > part in the vote. The vote should be conducted by secret ballot and > votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The > result will be determined by simple majority. If the vote of no > confidence in a WG Chair is passed, the seat is vacated and the WG Chair > is not eligible for stand for re-selection. > > ** No Chair: > > If a working group is left with no Chair, e.g. due to the resignation or > removal of the sole WG Chair, then the WG may elect an interim WG Chair > according to the selection procedures specified above, but with > candidates nominated at the WG session. An interim WG Chair must resign > at the next WG session, but may stand for re-selection. > > ** Staggered Introduction: > > For the purposes of staggering the introduction of this policy, in the > case where all co-Chairs of a WG have served for more than the standard > WG Chair term limit, an optional waiver is given to these WGs to allow > them to schedule the automatic resignations of their Chairs over the two > RIPE meetings immediately following the adoption of this policy. If the > WG decides to avail of this waiver, it is the responsibility of the WG > to decide in what order its co-Chairs should stand down. > > -- Dave Crocker Brandenburg InternetWorking bbiw.net From ops.lists at gmail.com Fri Sep 26 16:34:37 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 26 Sep 2014 20:04:37 +0530 Subject: [anti-abuse-wg] Appointment & Removal of Working Group Chairs In-Reply-To: <54256D3C.9050708@dcrocker.net> References: <54253094.7070309@heanet.ie> <54256D3C.9050708@dcrocker.net> Message-ID: Quite. It is interesting to see just how many people just happen to drift into the room for their first sig meeting, right in time for the vote of no confidence.. Rough consensus gets quite easy to manufacture, when organized that way. On 26-Sep-2014 7:13 pm, "Dave Crocker" wrote: > This obviously allows a form of ballot-box stuffing, by permitting votes > from people who have not been involved in the wg up to that point. I > have no idea how to prevent this, however. In addition, it can be > argued that anyone garnering enough ire to motivate the ballot-stuffing > effort probably is causing serious problems. The counter to that is > that they might be standing up to efforts to coerce the wg... -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.nisbet at heanet.ie Mon Sep 29 18:12:34 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 29 Sep 2014 17:12:34 +0100 Subject: [anti-abuse-wg] Appointment & Removal of Working Group Chairs In-Reply-To: <54256D3C.9050708@dcrocker.net> References: <54253094.7070309@heanet.ie> <54256D3C.9050708@dcrocker.net> Message-ID: <542984F2.3050809@heanet.ie> Dave, Thanks for your commentary on this, much appreciated! Dave Crocker wrote the following on 26/09/2014 14:42: > On 9/26/2014 2:23 AM, Brian Nisbet wrote: >> Tobias & I would like to present the text below as a starting point for >> this discussion > > These are always fun exercises... They are, but necessary ones, I think. > >> Note on Language: Throughout this document the word Chair shall be used >> for both Chairs and Co-Chairs. >> >> ** Introduction: >> >> This document aims to provide outline procedures to deal with the tenure >> of RIPE Working Group Chairs. It applies to all RIPE Working Groups. > > This document outlines procedures dealing with the tenure... I think I'm missing your point here? >> ** WG Chair Term: >> >> The normal term for a WG Chair is three years, after which the WG Chair >> must resign. A WG Chair may stand for re-selection after resignation. A >> WG Chair may resign voluntarily at any time. > > As phrased, this means that there is a gap between resignation and > filling the spot with the replacement chair. And if the resignation is > 'forced' it isn't really a resignation; it's just the end of their term. > > Perhaps: > > The term of a WG Chair is three years. A current chair may stand for > re-selection at the end of their term. A WG Chair may resign > voluntarily at any time. The "gap" should be no longer than a RIPE meeting and isn't really a big thing. The wording change, yup, I've no problem with that. >> ** Selection of a WG Chair: >> >> WG Chair vacancies, along with a call for candidates, should be > > should -> must > > Seems essential to make the minimum announcement time mandatory. Ah, yes, this isn't an RFC, so language thing, perfectly happy with must. >> announced on the WG mailing list at least one month in advance of the >> date upon which the selection will be held. The announcement should set >> a closing date for candidates. A WG may request that a WG Chair vacancy > > a WG Chair vacancy -> an additional WG Chair position Ok. > >> be opened so long as the addition of a new Chair would not cause the >> number of Chairs of that WG to exceed the maximum number specified in >> this document. > > I didn't see where that maximum was specified. There's a reason I left out this line: Reference Documents: Working Group Chair Job Description and Procedures (RIPE-542) I've no idea what that reason was, mind, but I'm sure it exists. Anyway, RIPE-542 specifies a maximum of three. >> WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically >> present at the WG session is eligible to participate in the selection >> process. The candidate does not need to be physically present at the WG >> session. >> >> If possible the Chair should be elected by acclamation by the WG or by >> consensus after discussion. If the result is unclear, then a secret >> ballot should be held. In the case of a ballot, votes will be counted by >> RIPE NCC Staff and/or Chairs of other WGs. The result will be determined >> by simple majority. >> >> ** Removal of a WG Chair: >> >> A WG Chair may be unable to fulfil their duties as described in this >> document or otherwise fail to serve the WG and the community. With the >> endorsement of a significant share of the WG, a vote of no confidence >> may be initiated. >> >> Before a vote of no confidence is taken, due effort should be made to >> address the issue(s) leading to the vote. The right of reply must be >> given to all parties involved in the procedure. If this effort fails to >> resolve the issue, the vote may proceed. >> >> The vote must be requested on the WG mailing list at least one week in >> advance of the WG Session at a RIPE meeting and should take place during >> the WG session. Anyone physically present at the WG session may take > > This obviously allows a form of ballot-box stuffing, by permitting votes > from people who have not been involved in the wg up to that point. I > have no idea how to prevent this, however. In addition, it can be > argued that anyone garnering enough ire to motivate the ballot-stuffing > effort probably is causing serious problems. The counter to that is > that they might be standing up to efforts to coerce the wg... It does, potentially, and this has been a bone of contention in other discussions. I have no idea how to prevent it either. Possibly more to the point I have no evidence to suggest it would or would not happen. Bussing in people at ?350 a pop to remain co-chair of a RIPE WG would seem... frankly insane. That's not to say it'll never happen, of course, but wow. There is, btw, the notion of popping in a consensus stage before the voting stage in a no-confidence motion. It doesn't remove the vote stuffing concern, of course, but it brings the whole thing more in line with preferred RIPE procedure. Brian From dhc at dcrocker.net Mon Sep 29 20:20:03 2014 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 29 Sep 2014 11:20:03 -0700 Subject: [anti-abuse-wg] Appointment & Removal of Working Group Chairs In-Reply-To: <542984F2.3050809@heanet.ie> References: <54253094.7070309@heanet.ie> <54256D3C.9050708@dcrocker.net> <542984F2.3050809@heanet.ie> Message-ID: <5429A2D3.1090605@dcrocker.net> On 9/29/2014 9:12 AM, Brian Nisbet wrote: >>> This document aims to provide outline procedures to deal with the tenure >>> of RIPE Working Group Chairs. It applies to all RIPE Working Groups. >> >> This document outlines procedures dealing with the tenure... > > I think I'm missing your point here? Wordsmithing. This was merely an offer of more concise and direct phrasing. Self-assessment or self-prediction language in documents tends to add only verbosity and distraction. So for example, something like "aims to provide" isn't needed. Either the document does what it intends, or it needs fixing. At the least, I prefer documents that are self-confident that they actually do what they intend, in terms of defining things. Self-doubt about eventual efficacy is always a different matter... >>> ** WG Chair Term: >>> >>> The normal term for a WG Chair is three years, after which the WG Chair >>> must resign. A WG Chair may stand for re-selection after resignation. A >>> WG Chair may resign voluntarily at any time. >> >> As phrased, this means that there is a gap between resignation and >> filling the spot with the replacement chair. And if the resignation is >> 'forced' it isn't really a resignation; it's just the end of their term. >> >> Perhaps: >> >> The term of a WG Chair is three years. A current chair may stand for >> re-selection at the end of their term. A WG Chair may resign >> voluntarily at any time. > > The "gap" should be no longer than a RIPE meeting and isn't really a big > thing. The wording change, yup, I've no problem with that. My point is that I'm pretty sure there is no gap intended, or at least there shouldn't be, for normally cycling of occupancy. I'd expect the group to want to have the chair seat always occupied. (That is, for cases other than mid-term resignation.) The normal model for normal cycles is that a sitting chair holds the position until the moment the next cycle of the chair puts the next occupant into it. (The fact that the current and next might be the same person doesn't affect this bit of formal modeling.) >>> ** Selection of a WG Chair: >>> >>> WG Chair vacancies, along with a call for candidates, should be >> >> should -> must >> >> Seems essential to make the minimum announcement time mandatory. > > Ah, yes, this isn't an RFC, so language thing, perfectly happy with must. Hadn't meant to invoke RFC formalities as much as simple, natural-language vocabulary semantics. 'Should' tends to be advisory and the sentence here seems to call for an absolute requirement. >>> be opened so long as the addition of a new Chair would not cause the >>> number of Chairs of that WG to exceed the maximum number specified in >>> this document. >> >> I didn't see where that maximum was specified. > > There's a reason I left out this line: > > Reference Documents: Working Group Chair Job Description and Procedures > (RIPE-542) > > I've no idea what that reason was, mind, but I'm sure it exists. Anyway, > RIPE-542 specifies a maximum of three. My main concern was that the text promised "in this document". Perhaps the next text is a revision to 542? Sorry if I missed that bit of context. In any event, since the max is indeed specify somewhere, rather than have text making the promise, perhaps just include a citation to the text (in 'this' document or the external one)? >> This obviously allows a form of ballot-box stuffing, by permitting votes >> from people who have not been involved in the wg up to that point. I >> have no idea how to prevent this, however. In addition, it can be >> argued that anyone garnering enough ire to motivate the ballot-stuffing >> effort probably is causing serious problems. The counter to that is >> that they might be standing up to efforts to coerce the wg... > > It does, potentially, and this has been a bone of contention in other > discussions. I have no idea how to prevent it either. Possibly more to > the point I have no evidence to suggest it would or would not happen. > Bussing in people at ?350 a pop to remain co-chair of a RIPE WG would > seem... frankly insane. That's not to say it'll never happen, of course, > but wow. > > There is, btw, the notion of popping in a consensus stage before the > voting stage in a no-confidence motion. It doesn't remove the vote > stuffing concern, of course, but it brings the whole thing more in line > with preferred RIPE procedure. For organizations trying to be dominated by overall community goodwill rather that by artificial and strict procedural formalities -- and I think ripe still falls into the former category -- I'm inclined to suggest some sort of community 'smell' text. That is, having a safety mechanism which calls for the community at large to step back and decide whether it thinks the overall tone of an activity feels acceptable. However I've never seen this idea applied as a formal construct, and I fear that the last time I saw it applied was as the ad hoc, spontaneous effort after the IETF's Kobe blowup, 20+ years ago, that took authority from the IAB and moved it to the IESG. (The popular view is that this was a successful exercise, and given the timespan from then to now, it probably was...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net