From ripedenis at yahoo.co.uk Tue May 5 15:59:01 2015 From: ripedenis at yahoo.co.uk (denis walker) Date: Tue, 5 May 2015 13:59:01 +0000 (UTC) Subject: [anti-abuse-wg] abuse-c cleanup Message-ID: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Hi All When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was:-allowing 6 months to deploy to all members allocations-then 12 months to deploy to all independent resources-then do a cleanup The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database. I think it is time to schedule that cleanup. Can the RIPE NCC confirm that all resources now have an "abuse-c:"? cheersDenis WalkerIndependent Netizen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.com Tue May 5 17:15:55 2015 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Tue, 5 May 2015 15:15:55 +0000 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Message-ID: +1 I?d assume most do at this stage ? it would be good to get confirmation of same Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: denis walker Reply-To: denis walker Date: Tuesday 5 May 2015 14:59 To: "anti-abuse-wg at ripe.net" Subject: [anti-abuse-wg] abuse-c cleanup Hi All When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was: -allowing 6 months to deploy to all members allocations -then 12 months to deploy to all independent resources -then do a cleanup The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database. I think it is time to schedule that cleanup. Can the RIPE NCC confirm that all resources now have an "abuse-c:"? cheers Denis Walker Independent Netizen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at ripe.net Wed May 6 17:18:06 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Wed, 6 May 2015 17:18:06 +0200 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Message-ID: Dear colleagues, > On 05 May 2015, at 15:59, denis walker wrote: > > When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was: > -allowing 6 months to deploy to all members allocations > -then 12 months to deploy to all independent resources > -then do a cleanup I believe you are referring to this: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 > Can the RIPE NCC confirm that all resources now have an "abuse-c:"? No, there are still organisations without abuse-c associated with resources. 1 = Some LIRs are still missing abuse-c Once the abuse-c has been set up for an organisation it cannot be removed, although it can be modified. However, "abuse-c:" still needs to be set for some LIRs created after phase-1 was completed. This is due to the fact that until recently new LIRs needed to create their own maintainer, abuse-c role object manually after membership activation. So new cases of LIRs that do not have an abuse-c set up were added every day. We updated the member activation process recently and now a maintainer and abuse-c role are created as part of the activation process. So, going forward we can now contact the remaining LIRs to set the abuse-c, and be sure that no new cases are created. We have not done this yet, because we were focusing on implementing the phase 1 and 2 of deprecating changed first. 2 = Not all organisations have an abuse-c The RIPE NCC only has a policy mandate to enforce abuse-c for organisations associated with resources allocated or assigned through the RIPE NCC. I.e. organisations holding legacy resources or assignments made by LIRs are not covered. > The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database. A schema change like this would need to be discussed in the database working group, and can only be done in case "abuse-c:" can be made mandatory for all organisations - and this would also have to be discussed there. From a technical point of view this change is not necessarily difficult to implement, provided that missing abuse-c roles could be created using either the existing abuse-mailbox or email attribute on organisations - presumably the addresses people would turn to today in the absence of an explicit abuse-c. So, in a way this change should not have a big semantic impact. Consistency would help to reduce complexity in documentation and business rules. It would also make it easier when assigning resources to new non-LIR organisations - now we need to check whether abuse-c has been set, because it's not mandatory and we often find that this makes dealing with requests longer. But that said, the above is only a partial picture of this, and this should in our view be discussed in the database working group. We can implement after consensus is called. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at yahoo.co.uk Wed May 6 19:26:39 2015 From: ripedenis at yahoo.co.uk (denis) Date: Wed, 06 May 2015 19:26:39 +0200 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Message-ID: <554A4ECF.7080104@yahoo.co.uk> An HTML attachment was scrubbed... URL: From Piotr.Strzyzewski at polsl.pl Thu May 7 10:38:21 2015 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 7 May 2015 10:38:21 +0200 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150507083821.GI22923@hydra.ck.polsl.pl> On Wed, May 06, 2015 at 05:18:06PM +0200, Tim Bruijnzeels wrote: Dear WG Members > > The idea of "abuse-c:" was to create one single place/way of > > documenting abuse contact details. So far all that has been achieved > > is to add a fourth way to document it. All the old ways > > ("abuse-mailbox:" in 5 object types, IRT and remarks) are still > > littered throughout the database. > > > A schema change like this would need to be discussed in the database > working group, and can only be done in case "abuse-c:" can be made > mandatory for all organisations - and this would also have to be > discussed there. > > From a technical point of view this change is not necessarily > difficult to implement, provided that missing abuse-c roles could be > created using either the existing abuse-mailbox or email attribute on > organisations - presumably the addresses people would turn to today in > the absence of an explicit abuse-c. So, in a way this change should > not have a big semantic impact. Consistency would help to reduce > complexity in documentation and business rules. It would also make it > easier when assigning resources to new non-LIR organisations - now we > need to check whether abuse-c has been set, because it's not mandatory > and we often find that this makes dealing with requests longer. > > But that said, the above is only a partial picture of this, and this > should in our view be discussed in the database working group. We can > implement after consensus is called. I agree with that. Denis do you want to make a follow-up on DB-WG? Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From gilles.massen at restena.lu Thu May 7 19:06:36 2015 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 07 May 2015 19:06:36 +0200 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> Message-ID: <554B9B9C.7060101@restena.lu> Hi, On 5/5/2015 15:59 , denis walker wrote: > The first two steps are done, but the last one seems to have been > overlooked. The idea of "abuse-c:" was to create one single place/way of > documenting abuse contact details. So far all that has been achieved is > to add a fourth way to document it. All the old ways ("abuse-mailbox:" > in 5 object types, IRT and remarks) are still littered throughout the > database. > > I think it is time to schedule that cleanup. I'd like to have the "cleanup" defined and discussed before doing it. The 'remarks' are obviously not really useful, and the abuse-c seems to replace functionally the abuse-mailbox (except that I still miss a 'more specific' abuse-c). The IRT objects are different though, and have features that the abuse-c lacks. So unless the abuse-c is able to replace the IRT, I'd object to deleting those. (to be specific: I'd hate to lose the signature and encryption fields - I think it was a mistake not to add those to the abuse-c from the start) best, Gilles From ripedenis at yahoo.co.uk Thu May 7 19:23:42 2015 From: ripedenis at yahoo.co.uk (denis) Date: Thu, 07 May 2015 19:23:42 +0200 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: <554B9B9C.7060101@restena.lu> References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> <554B9B9C.7060101@restena.lu> Message-ID: <554B9F9E.3040008@yahoo.co.uk> Hi Gilles I have just submit a proposal to the DB WG on the cleanup process. There was some discussion a long time ago on converting IRT object into ROLE objects, but that discussion was never brought to any conclusion. I don't propose to include that in this cleanup. cheers Denis Walker Independent Netizen On 07/05/2015 19:06, Gilles Massen wrote: > Hi, > > On 5/5/2015 15:59 , denis walker wrote: > >> The first two steps are done, but the last one seems to have been >> overlooked. The idea of "abuse-c:" was to create one single place/way of >> documenting abuse contact details. So far all that has been achieved is >> to add a fourth way to document it. All the old ways ("abuse-mailbox:" >> in 5 object types, IRT and remarks) are still littered throughout the >> database. >> >> I think it is time to schedule that cleanup. > I'd like to have the "cleanup" defined and discussed before doing it. > The 'remarks' are obviously not really useful, and the abuse-c seems to > replace functionally the abuse-mailbox (except that I still miss a 'more > specific' abuse-c). The IRT objects are different though, and have > features that the abuse-c lacks. So unless the abuse-c is able to > replace the IRT, I'd object to deleting those. > > (to be specific: I'd hate to lose the signature and encryption fields - > I think it was a mistake not to add those to the abuse-c from the start) > > best, > Gilles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.davis at jisc.ac.uk Fri May 8 11:26:12 2015 From: james.davis at jisc.ac.uk (James Davis) Date: Fri, 8 May 2015 10:26:12 +0100 Subject: [anti-abuse-wg] abuse-c cleanup In-Reply-To: <554B9B9C.7060101@restena.lu> References: <189934370.680418.1430834341594.JavaMail.yahoo@mail.yahoo.com> <554B9B9C.7060101@restena.lu> Message-ID: <554C8134.9000700@jisc.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/05/2015 18:06, Gilles Massen wrote: > I'd like to have the "cleanup" defined and discussed before doing > it. The 'remarks' are obviously not really useful, and the abuse-c > seems to replace functionally the abuse-mailbox (except that I > still miss a 'more specific' abuse-c). The IRT objects are > different though, and have features that the abuse-c lacks. So > unless the abuse-c is able to replace the IRT, I'd object to > deleting those. I've never seen an IRT object in the wild outside of the Trusted Introducer community, and when I encounter them they're usually for people/teams I personally know. Are there any statistics on how many exist? I'm also not sure which of the unique attributes actually get used - I've looked up IRT objects I don't think I've ever used the signature, encryption, or fax-no attributes. The need for all the features should be balanced against the benefits of a simple and consistent approach. I don't attend Trusted Introducer meetings at the moment but the steering committee is represented here :) James - -- James Davis, Information Security Manager +44 1235 822229 Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBAgAGBQJVTIE0AAoJED9R4Wv4u3eiQZoQAIEpjYfAKqjqnY6WlNTwdTN6 Pj/EykdbVJa3k9yXOt9okGuK0zcFJuc8ipz8DGx1OOlC9zlP7VXjWh72Oy0ck50F fVL9WskBEYvW1FlWADe/ykSZTbMCALPiIUo4DaZsGRSS7e+67paCQwDAyIlh314z hXBXZ9EaLyM8YHScbCBPFgw2aEaWfCehWJWCtO5+Wfqo3lZJ1T/6lXB7RuThwytA K48C9vdx3O/4W9CZvfmxPh6eFEyVHG+TULrVXtRZun6VPwTdxDydQ0UIC4o8VpGO y2dqai+fBzadJtGKw/1qF12pJQYYwyQKCvzW1mO6j8la8Sd1U6LbMxmYzuMxBgh8 P2ZyUB3gYsGguTEHdyEdRVe9Z+vWO268jznShRPnq7ir0Qq/S+OX/ssCyfTukXFe FXx/m65ZV5//xUHrGcnew4ih52PCmWjdpw91Icv9+R8b6A2ATMWN4hdDxU6PZDLA QBvNNCJnm13U1L3uMbwCbWGRNGRvHo3EehFxC4hEU+uKdZi5ydrz7QgnVfM9t/eu ubCMhw7nPAPcMMf7xTrKKjdd0CIdvnJz4PoRiQTI/IDy2I5LuFvlIYGlhI/wb0io 8wgF4kbQzTju67wu18q8BnQG2OFwBwJLEaXslAfy4iZcXyN3fLTMij9jgW9k3ZQm y1nJVEKxShTtBIoyxhFb =RrGF -----END PGP SIGNATURE----- Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc?s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. From brian.nisbet at heanet.ie Mon May 11 14:08:14 2015 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 11 May 2015 14:08:14 +0200 Subject: [anti-abuse-wg] Third Draft Agenda, RIPE70 Anti-Abuse WG Meeting Message-ID: <55509BAE.2060804@heanet.ie> Colleagues, Please find below the current draft agenda for the Anti-Abuse WG meeting at RIPE 70. The meeting will take place on Wednesday 13th May at 14:00 CEST. Unfortunately "User-experience of abuse-c & possible extensions" - Elliott Ingram, Entura International has had to be removed but hopefully it or something similar will reappear at another meeting soon. This does mean we might have a little spare time, so if anyone has anything they would like to bring up or take some time at the meeting session, please let me know as soon as possible. Thanks, Brian A. Administrative Matters - 5' * Welcome * Scribe, Jabber, Stenography * Microphone Etiquette * Approve Minutes from RIPE 69 * Finalise agenda B. Update - 15' * B1. Recent List Discussion * B2. AA-WG Chair Matters C. Policies - 0' D. Interactions - 5' * D1. Working Groups * D2. RIPE NCC Gov/LEA Interactions Update E. Presentation - 50' * E1. Mapping out Cyber Crime Infrastructure - A Law Enforcement Approach - Jon Flaherty UK National Crime Agency National Cyber Crime Unit * E2. "DNS-Based DDoS: Fast Changing Threat" - Bruce Van Nice, Nominum X. A.O.B. Z. Agenda for RIPE 71 From h.lu at anytimechinese.com Sun May 24 21:09:06 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Sun, 24 May 2015 21:09:06 +0200 Subject: [anti-abuse-wg] how many of you received following email Message-ID: This is getting....awaked: subject:[ncc-announce] [news] IPv4 address policy Hello. As you know, the RIPE NCC can only provide one final /22 to your LIR because it is currently allocating address space from the last /8 of IPv4 addresses. However the RIPE NCC allows to get IPv4 addresses from other LIR. Our company has LIR status and ready to transfer such addresses to your LIR. This operation is approved by the RIPE NCC and absolutely legal. The blocks are absolutely clean, haven't been in usage, are absent in any blacklists. If you have any further questions, don't hesitate to ask me. Simply answer to this letter and you will get the answer shortly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Sun May 24 21:17:30 2015 From: sergey at devnull.ru (Sergey Myasoedov) Date: Sun, 24 May 2015 21:17:30 +0200 Subject: [anti-abuse-wg] how many of you received following email In-Reply-To: References: Message-ID: <3CE5CB07-3EAF-4E75-9DFE-65FE575EF204@devnull.ru> Oh yes. It?s annoying. Almost every day. :( -- Kind regards, Sergey Myasoedov > On 24 May 2015, at 21:09, Lu Heng wrote: > > This is getting....awaked: > > > > subject:[ncc-announce] [news] IPv4 address policy > > > > Hello. > > As you know, the RIPE NCC can only provide one final /22 to your LIR because it is currently allocating address space from the last /8 of IPv4 addresses. > > However the RIPE NCC allows to get IPv4 addresses from other LIR. Our company has LIR status and ready to transfer such addresses to your LIR. This operation is approved by the RIPE NCC and absolutely legal. > > The blocks are absolutely clean, haven't been in usage, are absent in any blacklists. > > If you have any further questions, don't hesitate to ask me. Simply answer to this letter and you will get the answer shortly. > > > From stolpe at resilans.se Mon May 25 12:51:51 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 May 2015 12:51:51 +0200 (CEST) Subject: [anti-abuse-wg] how many of you received following email In-Reply-To: <3CE5CB07-3EAF-4E75-9DFE-65FE575EF204@devnull.ru> References: <3CE5CB07-3EAF-4E75-9DFE-65FE575EF204@devnull.ru> Message-ID: Several the same day. On Sun, 24 May 2015, Sergey Myasoedov wrote: > > Oh yes. It?s annoying. Almost every day. :( > > > -- > Kind regards, > Sergey Myasoedov > >> On 24 May 2015, at 21:09, Lu Heng wrote: >> >> This is getting....awaked: >> >> >> >> subject:[ncc-announce] [news] IPv4 address policy >> >> >> >> Hello. >> >> As you know, the RIPE NCC can only provide one final /22 to your LIR because it is currently allocating address space from the last /8 of IPv4 addresses. >> >> However the RIPE NCC allows to get IPv4 addresses from other LIR. Our company has LIR status and ready to transfer such addresses to your LIR. This operation is approved by the RIPE NCC and absolutely legal. >> >> The blocks are absolutely clean, haven't been in usage, are absent in any blacklists. >> >> If you have any further questions, don't hesitate to ask me. Simply answer to this letter and you will get the answer shortly. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From bengan at resilans.se Tue May 26 11:03:31 2015 From: bengan at resilans.se (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Tue, 26 May 2015 11:03:31 +0200 Subject: [anti-abuse-wg] how many of you received following email In-Reply-To: References: Message-ID: <556436E3.5060307@resilans.se> Yes. several. Apparently from ALB-MNT Den 2015-05-24 21:09, Lu Heng skrev: > This is getting....awaked: > > > > subject:[ncc-announce] [news] IPv4 address policy > > > Hello. > > As you know, the RIPE NCC can only provide one final /22 to your LIR > because it is currently allocating address space from the last /8 of > IPv4 addresses. > > However the RIPE NCC allows to get IPv4 addresses from other LIR. Our > company has LIR status and ready to transfer such addresses to your > LIR. This operation is approved by the RIPE NCC and absolutely legal. > > The blocks are absolutely clean, haven't been in usage, are absent in > any blacklists. > > If you have any further questions, don't hesitate to ask me. Simply > answer to this letter and you will get the answer shortly. > > -- Bengt G?rd?n Resilans AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bart at bit.nl Tue May 26 11:15:54 2015 From: bart at bit.nl (Bart Vrancken) Date: Tue, 26 May 2015 11:15:54 +0200 Subject: [anti-abuse-wg] how many of you received following email In-Reply-To: <556436E3.5060307@resilans.se> References: <556436E3.5060307@resilans.se> Message-ID: <556439CA.1020902@bit.nl> Hi, >> This is getting....awaked: Yeah, us too. Mainly on abuse@ and other harvested addresses from whois it seems. -- Met vriendelijke groet, Bart Vrancken, Engineer BIT BV | bart at bit.nl | +31 318 648688 Kvk: 09090351 | CROS-RIPE | GPG 3A99BD6E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: