From jochem at ripe.net Tue Apr 12 06:40:25 2011 From: jochem at ripe.net (Jochem de Ruig) Date: Tue, 12 Apr 2011 06:40:25 +0200 Subject: [acm-tf] Date and time next ACM-TF meeting Message-ID: <4DA3D7B9.4070509@ripe.net> Dear all, The next meeting for the Abuse Contact Management Task Force is scheduled for: *2 May 10:30 - 13:00* The meeting will take place at: * The Dam Room 1st floor, Krasnapolsky Hotel, Amsterdam, NL* Web/tele conference facilities will be arranged for the meeting. There will a change in the support for the ACM-TF from the RIPE NCC side. Paul Palse will leave our employment by the end of April. Kaveh Ranjbar will take on all RIPE DB duties and will take place in the ACM-TF per direct. Please let Kaveh and me know whether you will attend and whether this will be in person or by web/tele conference. Regards, Jochem de Ruig RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Tue Apr 12 06:53:54 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 12 Apr 2011 10:23:54 +0530 Subject: [acm-tf] Date and time next ACM-TF meeting In-Reply-To: <4DA3D7B9.4070509@ripe.net> References: <4DA3D7B9.4070509@ripe.net> Message-ID: Is that 10:30 Amsterdam time? On Tue, Apr 12, 2011 at 10:10 AM, Jochem de Ruig wrote: > The next meeting for the Abuse Contact Management Task Force is scheduled > for: > 2 May 10:30 - 13:00 -- Suresh Ramasubramanian (ops.lists at gmail.com) From vesely at tana.it Tue Apr 12 09:55:52 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 12 Apr 2011 09:55:52 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA3D7B9.4070509@ripe.net> References: <4DA3D7B9.4070509@ripe.net> Message-ID: <4DA40588.6040903@tana.it> On 12/Apr/11 06:40, Jochem de Ruig wrote: > The next meeting for the Abuse Contact Management Task Force is > scheduled for: > > *2 May 10:30 - 13:00* Not mentioned in http://ripe62.ripe.net/programme/meeting-plan > The Dam Room 1st floor, Krasnapolsky Hotel, Amsterdam, NL* Will there be room to hang a poster illustrating how abuse contacts are expected to work and play a role in the current scenario? If yes, I think we can quickly agree on some relevant points and arrange them nicely in a drawing. The drawing may illustrate a flow scheme, e.g. like http://wiki.asrg.sp.am/wiki/Abuse_Reporting (the picture on that page can actually be used as a starting point.) I candidate myself for producing SVG drafts to be discussed here, and printing the final poster(s). From tk at abusix.com Tue Apr 12 10:55:28 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 12 Apr 2011 10:55:28 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA40588.6040903@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> Message-ID: <4DA41380.3070107@abusix.com> > Will there be room to hang a poster illustrating how abuse contacts > are expected to work and play a role in the current scenario? Don't get me wrong ;-) but does it really matter on how abuse contacts are expected to work? and play a role in the current scenario? Does it really matter on how tech-c or admin-c or IRT contacts are expected to work? and play a role in the current scenario? I would not go to far with this TF at the moment. We should talk about a way on how abuse contact information can be inserted into the whois database in an easy way. And how we can ensure that querying these information is as easy as publishing them. > If yes, I think we can quickly agree on some relevant points and > arrange them nicely in a drawing. The drawing may illustrate a flow > scheme, e.g. like http://wiki.asrg.sp.am/wiki/Abuse_Reporting > (the picture on that page can actually be used as a starting point.) > I candidate myself for producing SVG drafts to be discussed here, and > printing the final poster(s). In my opinion there are just 3 pieces. The sender (in this case the complainant). The abuse contact addressbook (in this case the whois database). The receiver (in this case the abuse contact). This TF should in my opinion just look at two things. How can the Sender find the appropriate contact information in an easy way and without any restrictions? How can the Receiver publish his information in an appropriate and generic way? One thing about the wiki page. We need to be careful to not mix up user generated feedbackloops about spam and real thread reports about everything + spam. Feedbackloops are a completely different ecosystem. They are usually on subscription only and it's only about spam. Real thread reports cover much more than spam and are usually not subscription based. Subscribing to a service will usually give me the opportunity to define the email address I would like to receive the information. The problem starts when somebody is not offering a subscription and does not know where to look for the appropriate contact information. That's where we should start. Thanks, Tobias -- abusix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Tue Apr 12 14:28:54 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 12 Apr 2011 14:28:54 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA41380.3070107@abusix.com> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA41380.3070107@abusix.com> Message-ID: <4DA44586.7080807@tana.it> On 12/Apr/11 10:55, Tobias Knecht wrote: >> I candidate myself for producing SVG drafts to be discussed here, and >> printing the final poster(s). > > In my opinion there are just 3 pieces. > > The sender (in this case the complainant). > The abuse contact addressbook (in this case the whois database). > The receiver (in this case the abuse contact). Let me attach a draft example. Does anyone have difficulties with it? As an alternative, I could park PNGs somewhere on the web... > This TF should in my opinion just look at two things. > > How can the Sender find the appropriate contact information in an easy > way and without any restrictions? > > How can the Receiver publish his information in an appropriate and > generic way? A third thing is to maintain this information. In order for a Sender to confidently send a report to a Receiver, someone has to collect assessments about their trustworthiness, so that they can reliably understand each other. > One thing about the wiki page. We need to be careful to not mix up user > generated feedbackloops about spam and real thread reports about > everything + spam. Yes, but being careful implies considering them. > Feedbackloops are a completely different ecosystem. They are usually on > subscription only and it's only about spam. Currently it is like so. However, I counted less than a dozen of those FBLs, all of which are located in North America. > Real thread reports cover much more than spam and are usually not > subscription based. Some kind of FBL may also be not subscription based. > Subscribing to a service will usually give me the opportunity to define > the email address I would like to receive the information. The problem > starts when somebody is not offering a subscription and does not know > where to look for the appropriate contact information. > > That's where we should start. -------------- next part -------------- A non-text attachment was scrubbed... Name: acm-tf.svg Type: image/svg+xml Size: 141444 bytes Desc: not available URL: From vesely at tana.it Tue Apr 12 18:01:53 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 12 Apr 2011 18:01:53 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA41380.3070107@abusix.com> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA41380.3070107@abusix.com> Message-ID: <4DA47771.1070200@tana.it> On 12/Apr/11 10:55, Tobias Knecht wrote: > In my opinion there are just 3 pieces. > > The sender (in this case the complainant). > The abuse contact addressbook (in this case the whois database). > The receiver (in this case the abuse contact). I sketched a draft example http://www.tana.it/file/acm-tf.svg I cannot attach it to a list post, because there's a limit of 40 KB. Does anyone have difficulties with SVGs? Most browsers can display them. If needed, I'll put also PNGs. The example doesn't show connections among Sender, Receiver, and db yet. There's more on the threats. > This TF should in my opinion just look at two things. > > How can the Sender find the appropriate contact information in an easy > way and without any restrictions? > > How can the Receiver publish his information in an appropriate and > generic way? A third thing is to maintain this information. In order for a Sender to confidently send a report to a Receiver, someone has to collect assessments about their trustworthiness, so that they can reliably understand each other. > One thing about the wiki page. We need to be careful to not mix up user > generated feedbackloops about spam and real thread reports about > everything + spam. Yes, but being careful implies considering them. > Feedbackloops are a completely different ecosystem. They are usually on > subscription only and it's only about spam. Currently it is like so. However, I counted less than a dozen of those FBLs, all of which are located in North America. > Real thread reports cover much more than spam and are usually not > subscription based. Some kind of FBL may also be not subscription based. > Subscribing to a service will usually give me the opportunity to define > the email address I would like to receive the information. The problem > starts when somebody is not offering a subscription and does not know > where to look for the appropriate contact information. > > That's where we should start. From tk at abusix.com Tue Apr 12 22:20:51 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 12 Apr 2011 22:20:51 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA44586.7080807@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA41380.3070107@abusix.com> <4DA44586.7080807@tana.it> Message-ID: <4DA4B423.4050203@abusix.com> Hi again, > A third thing is to maintain this information. In order for a Sender > to confidently send a report to a Receiver, someone has to collect > assessments about their trustworthiness, so that they can reliably > understand each other. Imho way to complicated and impossible. The receiver is intelligent enough to decide on his own if he wants to trust the report coming from a complainant or not. If he does he can handle it, if he does not he can delete it. We should not start and talk about a classification of trustworthiness. This Taskforce has to find a way on how we want RIPE members to publish abuse contact information. This has nothing to do with any social interaction or the way how abuse departments handle their reports. >> One thing about the wiki page. We need to be careful to not mix up user >> generated feedbackloops about spam and real thread reports about >> everything + spam. > > Yes, but being careful implies considering them. That is true, but in this specific case I do not see any connection between both. >> Feedbackloops are a completely different ecosystem. They are usually on >> subscription only and it's only about spam. > > Currently it is like so. However, I counted less than a dozen of > those FBLs, all of which are located in North America. Right, this is just a legal problem in Europe. Maybe there will be feedbackloops that do not need subscription in future, which is in my definition not a feedbackloop anymore, it is "global reporting". I think we can agree that everybody who wants to report abusive behavior and does not have a direct source for the abuse contact (as it is handled with todays feedbackloops by subscription) needs a source to find the abuse contact. >> Real thread reports cover much more than spam and are usually not >> subscription based. > > Some kind of FBL may also be not subscription based. Right. The abusix "global reporting" is not subscription based. The Deutsche Telekom reporting is not, the TDC repoting is not. But we usually do not call it feedbackloops. Or is your definition of a feedbackloop just reporting abusive behavior back to its source? If that is the way we are talking different directions just by not having the same definition. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From jochem at ripe.net Wed Apr 13 03:05:38 2011 From: jochem at ripe.net (Jochem de Ruig) Date: Wed, 13 Apr 2011 03:05:38 +0200 Subject: [acm-tf] Date and time next ACM-TF meeting In-Reply-To: References: <4DA3D7B9.4070509@ripe.net> Message-ID: <4DA4F6E2.1040204@ripe.net> Yes, 10:30 Amsterdam time. Jochem On 4/12/11 6:53 AM, Suresh Ramasubramanian wrote: > Is that 10:30 Amsterdam time? > > On Tue, Apr 12, 2011 at 10:10 AM, Jochem de Ruig wrote: >> The next meeting for the Abuse Contact Management Task Force is scheduled >> for: >> 2 May 10:30 - 13:00 From jochem at ripe.net Wed Apr 13 03:08:58 2011 From: jochem at ripe.net (Jochem de Ruig) Date: Wed, 13 Apr 2011 03:08:58 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA40588.6040903@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> Message-ID: <4DA4F7AA.1050501@ripe.net> Dear Alessandro and all, This is a closed meeting only participants in the Task Force are invited hence this is not in the public program. Will make sure there is a flip-over and post-it's so we can work out your suggestion. Regards, Jochem On 4/12/11 9:55 AM, Alessandro Vesely wrote: > On 12/Apr/11 06:40, Jochem de Ruig wrote: >> The next meeting for the Abuse Contact Management Task Force is >> scheduled for: >> >> *2 May 10:30 - 13:00* > Not mentioned in http://ripe62.ripe.net/programme/meeting-plan >> The Dam Room 1st floor, Krasnapolsky Hotel, Amsterdam, NL* > Will there be room to hang a poster illustrating how abuse contacts > are expected to work and play a role in the current scenario? > > If yes, I think we can quickly agree on some relevant points and > arrange them nicely in a drawing. The drawing may illustrate a flow > scheme, e.g. like http://wiki.asrg.sp.am/wiki/Abuse_Reporting > (the picture on that page can actually be used as a starting point.) > I candidate myself for producing SVG drafts to be discussed here, and > printing the final poster(s). > > > From ops.lists at gmail.com Wed Apr 13 03:45:28 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 13 Apr 2011 07:15:28 +0530 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA4F7AA.1050501@ripe.net> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA4F7AA.1050501@ripe.net> Message-ID: I would suggest that we table Alessandro's discussion and he can raise it during the normal RIPE antiabuse WG instead, for broader public comment. On Wed, Apr 13, 2011 at 6:38 AM, Jochem de Ruig wrote: > > This is a closed meeting only participants in the Task Force are invited > hence this is not in the public program. > > Will make sure there is a flip-over and post-it's so we can work out > your suggestion. -- Suresh Ramasubramanian (ops.lists at gmail.com) From brian.nisbet at heanet.ie Wed Apr 13 10:45:02 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 13 Apr 2011 09:45:02 +0100 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA40588.6040903@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> Message-ID: <4DA5628E.2050009@heanet.ie> Alessandro, "Alessandro Vesely" wrote the following on 12/04/2011 08:55: > On 12/Apr/11 06:40, Jochem de Ruig wrote: >> The next meeting for the Abuse Contact Management Task Force is >> scheduled for: >> >> *2 May 10:30 - 13:00* > Not mentioned in http://ripe62.ripe.net/programme/meeting-plan >> The Dam Room 1st floor, Krasnapolsky Hotel, Amsterdam, NL* > > Will there be room to hang a poster illustrating how abuse contacts > are expected to work and play a role in the current scenario? > > If yes, I think we can quickly agree on some relevant points and > arrange them nicely in a drawing. The drawing may illustrate a flow > scheme, e.g. like http://wiki.asrg.sp.am/wiki/Abuse_Reporting > (the picture on that page can actually be used as a starting point.) > I candidate myself for producing SVG drafts to be discussed here, and > printing the final poster(s). I'm largely with Tobias here, I do not see this as part of the scope of the TF. To repeat the agreed points of the charter from the first meeting: - Should be a single logical path to document abuse POC - The current abuse POC data in the RIPE Database should be deprecated and/or migrated. - The target audience needs to be defined - Should it be mandatory? - Should include a best-practises document - Should there be a consequence attached for non-compliance? - It should be done in a way that it doesn?t fall under the ?Personal Data? restrictions While BCP is mentioned there, I do not think that expands to FBLs or the flow of an abuse complaint. As Suresh says, this may be far better placed in the AA-WG, although I'm not sure how much spare time we have in the session right now. Brian. From vesely at tana.it Wed Apr 13 14:22:08 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 13 Apr 2011 14:22:08 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA5628E.2050009@heanet.ie> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> Message-ID: <4DA59570.2000903@tana.it> On 13/Apr/11 10:45, Brian Nisbet wrote: > "Alessandro Vesely" wrote the following on 12/04/2011 08:55: >> Will there be room to hang a poster illustrating how abuse contacts >> are expected to work and play a role in the current scenario? > > I'm largely with Tobias here, I do not see this as part of the scope > of the TF. To repeat the agreed points of the charter from the first > meeting: > > - Should be a single logical path to document abuse POC > - The current abuse POC data in the RIPE Database should be deprecated > and/or migrated. > - The target audience needs to be defined > - Should it be mandatory? > - Should include a best-practises document > - Should there be a consequence attached for non-compliance? > - It should be done in a way that it doesn?t fall under the ?Personal > Data? restrictions I agree that those points don't formally require to describe the intended use of abuse POCs, let alone the effect that such use is expected to provoke. However, airing what are the real reasons why we want to do all that and gathering consensus from the community at large will help to accomplish our task effectively. > While BCP is mentioned there, I do not think that expands to FBLs or > the flow of an abuse complaint. I possibly misused the term "FBL", meaning what Tobias calls "global reporting" --see below. > As Suresh says, this may be far better placed in the AA-WG, > although I'm not sure how much spare time we have in the session > right now. Having such a session may be a neat idea too. Hanging a poster is just an easy and a rakish way to raise attention/consensus. On 13/Apr/11 03:08, Jochem de Ruig wrote: > Will make sure there is a flip-over and post-it's so we can work out > your suggestion. Thanks. I'll need the actual dimensions for printing. Knowing early if it is landscape or portrait will help. On 12/Apr/11 22:20, Tobias Knecht wrote: >> A third thing is to maintain this information. In order for a Sender >> to confidently send a report to a Receiver, someone has to collect >> assessments about their trustworthiness, so that they can reliably >> understand each other. > > Imho way to complicated and impossible. Let's keep this point off the poster, since we don't fully agree. >>> Feedbackloops are a completely different ecosystem. They are usually on >>> subscription only and it's only about spam. >> >> Currently it is like so. However, I counted less than a dozen of >> those FBLs, all of which are located in North America. > > Right, this is just a legal problem in Europe. Maybe there will be > feedbackloops that do not need subscription in future, which is in my > definition not a feedbackloop anymore, it is "global reporting". Yes, that's what I meant, whatever we'll call it. > I think we can agree that everybody who wants to report abusive behavior > and does not have a direct source for the abuse contact (as it is > handled with todays feedbackloops by subscription) needs a source to > find the abuse contact. Someone mentioned abuse at ripe.net will be put in use, some day. Perhaps, RIPE will just blindly forward reports to the relevant allocation-specific abuse POC, in some cases. In such cases, the Sender should find the target address directly (and thus optimize the traffic.) This consideration would suggest a "hierarchical database", in some sense. To depict it, we may represent a Receiver forwarding a report to a sub-allocation, e.g. an ISP to a customer of theirs. > The abusix "global reporting" is not subscription based. The > Deutsche Telekom reporting is not, the TDC repoting is not. But we > usually do not call it feedbackloops. AFAIK, the abusix db can be considered a sort of whois digest, rather than independent data. Dunno about the other two. Shall we depict multiple databases? > Or is your definition of a feedbackloop just reporting abusive > behavior back to its source? Yeah, sort of. I never saw a formal definition, but IMHO it should provide for reaching the original source --the author-- of a reported message, in some cases. > If that is the way we are talking different directions just by not > having the same definition. :-) Yup, most likely. Some definitions, a legend, and a title would complete the poster. From tk at abusix.com Wed Apr 13 14:42:34 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 13 Apr 2011 14:42:34 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA59570.2000903@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> Message-ID: <4DA59A3A.9030805@abusix.com> Hi again, > Someone mentioned abuse at ripe.net will be put in use, some day. > Perhaps, RIPE will just blindly forward reports to the relevant > allocation-specific abuse POC, in some cases. In such cases, the > Sender should find the target address directly (and thus optimize the > traffic.) This consideration would suggest a "hierarchical database", > in some sense. To depict it, we may represent a Receiver forwarding a > report to a sub-allocation, e.g. an ISP to a customer of theirs. I heard discussion about that as well. In theory this might be a good idea, but I guess in live this will not be practical. You can not filter spam on an abuse mailbox, so this would be a nice aim for spammers to destroy the idea. And even if we find a way of not getting killed by spammers, you will get killed by complaints. Some of your customers receive far more than 600 to 800 thousands complaints a day. abusix is sending more than 2 million complaints every day to ip space in the ripe region. This will come to an end before it really has started. ;-) >> The abusix "global reporting" is not subscription based. The >> Deutsche Telekom reporting is not, the TDC repoting is not. But we >> usually do not call it feedbackloops. > > AFAIK, the abusix db can be considered a sort of whois digest, rather > than independent data. Dunno about the other two. Shall we depict > multiple databases? They are using our DB. More than 300 different IPs per day query our caching database. So this shows that there is need for an official abuse contact phonebook and not a not complete phonebook by abusix ;-) >> Or is your definition of a feedbackloop just reporting abusive >> behavior back to its source? > > Yeah, sort of. I never saw a formal definition, but IMHO it should > provide for reaching the original source --the author-- of a reported > message, in some cases. Ah okay, than I got it. I was just to deep into my jargon that I didn't get it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Wed Apr 13 15:12:34 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Apr 2011 15:12:34 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA59A3A.9030805@abusix.com> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> <4DA59A3A.9030805@abusix.com> Message-ID: <4DA5A142.5020506@ripe.net> Tobias Knecht wrote: > Hi again, > > >> Someone mentioned abuse at ripe.net will be put in use, some day. >> Perhaps, RIPE will just blindly forward reports to the relevant >> allocation-specific abuse POC, in some cases. In such cases, the >> Sender should find the target address directly (and thus optimize the >> traffic.) This consideration would suggest a "hierarchical database", >> in some sense. To depict it, we may represent a Receiver forwarding a >> report to a sub-allocation, e.g. an ISP to a customer of theirs. >> > > I heard discussion about that as well. In theory this might be a good > idea, but I guess in live this will not be practical. > Just to clarify one point here. The email address abuse at ripe.net is the abuse mailbox address used by the RIPE NCC as an organisation. This is for handling any abuse complaints regarding the IP addresses in use by the RIPE NCC for our own infrastructure. It is not a generalised address for any abuse processes concerning the RIPE community or RIPE service region or RIPE NCC Members. Regards Denis Walker Business Analyst RIPE NCC Database Group > You can not filter spam on an abuse mailbox, so this would be a nice aim > for spammers to destroy the idea. And even if we find a way of not > getting killed by spammers, you will get killed by complaints. > > Some of your customers receive far more than 600 to 800 thousands > complaints a day. abusix is sending more than 2 million complaints every > day to ip space in the ripe region. > > This will come to an end before it really has started. ;-) > > >>> The abusix "global reporting" is not subscription based. The >>> Deutsche Telekom reporting is not, the TDC repoting is not. But we >>> usually do not call it feedbackloops. >>> >> AFAIK, the abusix db can be considered a sort of whois digest, rather >> than independent data. Dunno about the other two. Shall we depict >> multiple databases? >> > > They are using our DB. More than 300 different IPs per day query our > caching database. So this shows that there is need for an official abuse > contact phonebook and not a not complete phonebook by abusix ;-) > > >>> Or is your definition of a feedbackloop just reporting abusive >>> behavior back to its source? >>> >> Yeah, sort of. I never saw a formal definition, but IMHO it should >> provide for reaching the original source --the author-- of a reported >> message, in some cases. >> > > Ah okay, than I got it. I was just to deep into my jargon that I didn't > get it. > > > From vesely at tana.it Wed Apr 13 17:15:50 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 13 Apr 2011 17:15:50 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA5A142.5020506@ripe.net> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> <4DA59A3A.9030805@abusix.com> <4DA5A142.5020506@ripe.net> Message-ID: <4DA5BE26.8020004@tana.it> On 13/Apr/11 15:12, Denis Walker wrote: >>> Someone mentioned abuse at ripe.net will be put in use, some day. >> >> I heard discussion about that as well. In theory this might be a good >> idea, but I guess in live this will not be practical. > > Just to clarify one point here. The email address abuse at ripe.net is the > abuse mailbox address used by the RIPE NCC as an organisation. This is > for handling any abuse complaints regarding the IP addresses in use by > the RIPE NCC for our own infrastructure. It is not a generalised address > for any abuse processes concerning the RIPE community or RIPE service > region or RIPE NCC Members. Aha, I misunderstood the meaning of a message by Athina[1]. In retrospect, I guess I thought she meant the drafting of a new procedure, while she wrote "The drafting of this document is in progress." Thanks for the clarification [1] https://www.ripe.net/ripe/maillists/archives/anti-abuse-wg/2011/msg00057.html From pk at DENIC.DE Wed Apr 13 18:29:09 2011 From: pk at DENIC.DE (Peter Koch) Date: Wed, 13 Apr 2011 18:29:09 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <4DA59570.2000903@tana.it> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> Message-ID: <20110413162909.GR1366@x27.adm.denic.de> On Wed, Apr 13, 2011 at 02:22:08PM +0200, Alessandro Vesely wrote: > I agree that those points don't formally require to describe the > intended use of abuse POCs, let alone the effect that such use is intended by who? In addition to Brian's excerpt from the minutes, there i read "The first round about the charter focussed primarily on ?Documenting abuse POC in the RIPE Database? and proposal 2010-08 in particular. In general the following points were brought forward:" Also i see the forst of two bullet items in the draft charter: 1. Come up with a policy to describe how to document abuse related POC information in the RIPE Database that is both easy to maintain by resource holders, and easy to retrieve by different target audiences. So, i might have it compeletly wrong, but the proposed poster seems to give an answer to this already. If it were that easy ... Without dampening anybody's enthusiasm I think we should concentrate on the first steps, get the charter done and out of the door and maybe do some analysis of current mechanisms and maybe their weaknesses or other wise work on the list provided in the minutes. Any outreach appears a bit premature to me at this point in time. Looking forward to a productive meeting in A'dam! Regards, Peter From vesely at tana.it Thu Apr 14 19:34:36 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 14 Apr 2011 19:34:36 +0200 Subject: [acm-tf] Poster on theory of abuse contact management, was Date and time next ACM-TF meeting In-Reply-To: <20110413162909.GR1366@x27.adm.denic.de> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> <20110413162909.GR1366@x27.adm.denic.de> Message-ID: <4DA7302C.6060503@tana.it> On 13/Apr/11 18:29, Peter Koch wrote: > On Wed, Apr 13, 2011 at 02:22:08PM +0200, Alessandro Vesely wrote: > >> I agree that those points don't formally require to describe the >> intended use of abuse POCs, let alone the effect that such use is > > intended by who? By us, the acm-tf. But then, every other netizen who'll happen to like what we'll do will also expect something from it, won't they? > In addition to Brian's excerpt from the minutes, there i read [...] > > So, i might have it compeletly wrong, but the proposed poster seems to > give an answer to this already. If it were that easy ... You mean if producing a full blown spec were as easy as drawing it :-) > Without dampening anybody's enthusiasm I think we should concentrate on > the first steps, get the charter done and out of the door and maybe > do some analysis of current mechanisms and maybe their weaknesses or > other wise work on the list provided in the minutes. Far be it from me to divert valuable TF's time aside from real work. I only need minimal support to make sure we all agree on what the poster will say. We can effortlessly check that in our spare time. > Any outreach appears a bit premature to me at this point in time. Why premature? The original charter's draft timeline mentions Report on the task force's progress during RIPE 62 (May 2011) and collect regular input from the RIPE community which implies some sort of outreach at this point in time. OTOH, we may take precautions to avoid, for example, a new tide of subscriptions to the list, or excessive criticism, if that is a concern. From vesely at tana.it Thu Apr 14 20:13:22 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 14 Apr 2011 20:13:22 +0200 Subject: [acm-tf] Definitions of FBL and global reporting, was Poster In-Reply-To: <4DA59A3A.9030805@abusix.com> References: <4DA3D7B9.4070509@ripe.net> <4DA40588.6040903@tana.it> <4DA5628E.2050009@heanet.ie> <4DA59570.2000903@tana.it> <4DA59A3A.9030805@abusix.com> Message-ID: <4DA73942.5060202@tana.it> On 13/Apr/11 14:42, Tobias Knecht wrote: >>> Or is your definition of a feedbackloop just reporting abusive >>> behavior back to its source? >> >> Yeah, sort of. I never saw a formal definition, but IMHO it should >> provide for reaching the original source --the author-- of a reported >> message, in some cases. > > Ah okay, than I got it. I was just to deep into my jargon that I didn't > get it. My bad. There is a clear definition of FBL in [MLM]: A Feedback Loop (FBL) is a bi-lateral agreement between two parties to exchange reports of abuse. Typically, a sender registers with a receiving site to receive abuse reports from that site for mail coming from the sender. A more convoluted definition can be found in [FBL]. They both agree with the way you understood my misuse of that term. Then, there is that discovering draft [FRD], that interestingly uses the word feedback to coin a bunch of terms, like "feedback reporting advertisement". While I like the concept of global reporting, I personally don't like the term itself very much. It seems to me that, as it contains neither the word "abuse" nor "feedback", it doesn't unambiguously refer to the activity it means, and is too generic. [GRI] uses the same term. -- [MLM] http://tools.ietf.org/html/draft-ietf-dkim-mailinglists [FBL] http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp [FRD] http://tools.ietf.org/html/draft-ietf-marf-reporting-discovery [GRI] http://www.globalreporting.org/ From kranjbar at ripe.net Tue Apr 26 16:25:20 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 26 Apr 2011 16:25:20 +0200 Subject: [acm-tf] Draft Charter and Draft Agenda for upcoming ACM-TF Meeting Message-ID: <4DB6D5D0.1000509@ripe.net> Dear all, Please find the Draft Charter and Draft Agenda of upcoming Abuse Contact Management Task Force meeting below. You can also find a copy of the minutes of the last meeting at the end of this email. As a reminder, the meeting is scheduled for 2nd of May 2011, 8:30 - 11:00 UTC (10:30 - 13:00 Amsterdam Time) and will take place at "The Dam Room, 1st Floor of Krasnapolsky Hotel, Amsterdam, NL", instructions for joining by teleconference will be sent later to this list. Kind Regards, Kaveh Ranjbar Database Group Manager at RIPE NCC ------------------------------------------------------------------------------------ Draft Charter The Abuse Contact Management Task Force agrees on the following charter: This task force will: * Proposea policy to describe how to document abuse related POC information in the public RIPE Database that is both easy to maintain by resource holders, and easy to retrieve by different target audiences. * Proposeprocedures and implementation tools to ensure that anti abuse related data is and remains accurate. A rough timeline: * RIPE 62: Initiate policy discussions. Present charter during various WG meetings. * Between RIPE 62 and RIPE 63: Draft policy and define procedures and implementation tools * RIPE 63: Present outcome and estimate time to implement. ------------------------------------------------------------------------------------ Draft Agenda 1) Participants / Minutes last meeting / 2) Task Force Charter - Discuss updated charter proposal 3) ACM policy principles (what are the conditions the policy has to meet?) - Discuss principles for the policy proposal 4) ACM policy requirements (what do we want to achieve with the policy proposal?) 5) ACM policy content 6) ACM policy implementation ------------------------------------------------------------------------------------ Minutes of the first ACM Task Force meeting held on the 10th of March 2011 14:00 UTC *Participants* Brian Nisbet (Chair) Wilfried Woeber Peter Koch Tobias Knecht Suresh Ramasubramanian Alessandro Vesely Jochem Ruig Paul Palse *Administrative Matters* - Welcome - Select scribe (Paul, Jochem) - Finalise agenda: Agenda accepted. *Introduction of the task force members* There was a round of introductions. Everyone provided some information about their professional background and their motivation to join the ACM Task Force. *Background of the task force* Brian explained how the task force came about. During RIPE 61 in Rome three proposals were discussed, 2010-08, 2010-09 and 2010-10. It was felt that some of these proposals contained either too much implementation details, were too general or missed a clear problem statement. The most appropriate way forward was to set up a task force as a vehicle to define the problem statements outlined in the proposals and to formalise them into a coherent policy proposal or policy proposals to address them. *Task force name* The name: "Abuse Contact Management Task Force (ACM-TF)" was found to be appropriate. *The charter* The first round about the charter focused primarily on ?Documenting abuse POC in the RIPE Database? and proposal 2010-08 in particular. In general the following points were brought forward: - Should be a single logical path to document abuse POC - The current abuse POC data in the RIPE Database should be deprecated and/or migrated. - The target audience needs to be defined - Should it be mandatory? - Should include a best-practices document - Should there be a consequence attached for non-compliance? - It should be done in a way that it doesn?t fall under the ?Personal Data? restrictions Regarding ?Data quality in the RIPE Database? the following points were brought forward: - RIPE NCC mentioned that they found it was hard to find the right approach to find useful ?Abuse Contact? details, when they implemented the ?Abuse Finder? tool. - APNIC implemented the IRT object in the way as specified in proposal 2010-08, but also have a procedure to make sure that all other references to abuse related data in the form of abuse mailbox attributes on various other objects etc are cleaned up? *The charter for the task force* 1. Come up with a policy to describe how to document abuse related POC information in the RIPE Database that is both easy to maintain by resource holders, and easy to retrieve by different target audiences. 2. Put in place procedures and technology to ensure that anti abuse related data is and remains accurate. The RIPE NCC will work on the draft Charter and will send an updated version in April. *Other topics/remarks* - Task force membership is public by default. The RIPE Website will have a page dedicated to the taskforce and its participants including a short profile. If anyone feels uncomfortable with that please let the RIPE NCC know. - Tobias indicated his preference to address the ?Documenting abuse POC in the RIPE Database? issues first and then continue with the other aspects. This way we can see results much sooner. - Suresh raised the question if we need more involvement from other groups from the Internet security and anti abuse fields by inviting more participants to the Taskforce. In general it was felt that there is a fair representation of the different groups in the existing task force membership, also to contain the task force group the aim is to limit additional members. We can always invite others for specific topic if we feel we need input for missing expertise ( for instance a Legal Counsel ) *Next meeting* Set during RIPE 62, Krasnapolsky Hotel, Amsterdam. Monday 2nd May 10:30 Exact room details will be circulated to the participants as soon as they have been fixed. Remote participation will be facilitated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kranjbar at ripe.net Wed Apr 27 11:00:01 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Wed, 27 Apr 2011 11:00:01 +0200 Subject: [acm-tf] Meeting invitation: Abuse Contact Management Task Force Meeting Message-ID: <4DB7DB11.4050902@ripe.net> Hello, Please find below instructions for remotely joining the meeting. Kind Regards, Kaveh. ------------------------------------------------------- RIPE NCC invites you to attend this online meeting. Topic: Abuse Contact Management Task Force Meeting Date: Monday, May 2, 2011 Time: 10:30 am, Europe Summer Time (Amsterdam, GMT+02:00) Meeting Number: 708 786 433 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/j.php?ED=174298547&UID=1223266482&PW=NYWMyYWI5NWFl&RT=MiMyMg%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ripencc.webex.com/ripencc/j.php?ED=174298547&UID=1223266482&PW=NYWMyYWI5NWFl&ORT=MiMyMg%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (UK): 0800 028 1181 Call-in toll number (UK): (0)20 700 51000 Global call-in numbers: https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=174298547&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:708 786 433 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". You can contact us at: lenka.svobodova at ripe.net To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=174298547&UID=1223266482&ICS=MI&LD=1&RD=2&ST=1&SHA2=ty3/VyB8jUNsZ1dxOHZejwWny8LkWLirlPw0/HzdKG8=&RT=MiMyMg%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ripencc.webex.com/ripencc/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+02070051000x708786433# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------------- next part -------------- An HTML attachment was scrubbed... URL: