- db-wg - mailman.ripe.net

Re: [db-wg] Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Ronald F. Guilmette 20 Jun '17

20 Jun '17

In message <mailman.1675.1497881039.4885.db-wg(a)ripe.net>, Jeroen Massar <jeroen(a)massar.ch> wrote: >Really, a Dutch address, claiming a British country, while the prefix >clearly show "NL" as prefix. > >Website at http://www.onlineserviceproviderbv.nl/ is empty... You may have a bit more luck if you try this: http://onlineserviceproviderbv.nl/ But anyway, it still does seem quite odd that the IPv6 space of this "Dutch" company is apparently being routed by a company located in India whose main stock in trade is the manufacturing of portable searchlights. http://bgp.he.net/AS58905#_prefixes6 --> adwiser.co --> "Point Blank Range Pvt Ltd" --> https://www.indiamart.com/pointblank-rangeprivate-limited/ But it is all rather humorous, don't you think? (I personally prefer my Internet criminals to be ones with a sense of humor. It makes the process of hunting them down at least somewhat entertaining.) And if you would like to see even -more- humor, try this google search: "+31 20 218 2999" It would seem that your "Dutch Internet Service Provider" has another business which is even more notable (and even more linked to, going by the google results ordering), i.e. they also are apparently selling some sort of service that allegedly will help us all to MAKE MONEY FAST while gambling on sports games. https://oddstreak.com/terms-of-service https://oddstreak.com/ Terrific! I just can't wait to make my fortune betting on futbol and/or cricket matches, full time, and with every last penny I have. These people vitrually guarrantee that if I just put in the time and effort, and if I just give them a little bit of money every month, I'll soon be wealthy beyond my wildest dreams. I confess that it does seem just slightly odd that these people who are behind this commercial enterprise, having invested all of the time and energy needed to build a sophisticated mathematical system that will allow any ordinary man on the street (like me) to beat the odds and to come out a winner, would not have applied this system -themselves-, you know, to help their own betting. I mean gee! They have this sophisticated betting system which will allow you to win all the time, so why aren't they themselves presently lounging on a beach somewhere without a care in the world? I guess they are just too generous, and they felt obliged to share their magical mathematical betting strategies with even poor little sods like me. God bless them! covfefe

1 0

Re: [db-wg] Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Ronald F. Guilmette 20 Jun '17

20 Jun '17

In message <mailman.1675.1497881039.4885.db-wg(a)ripe.net>, Jeroen Massar <jeroen(a)massar.ch> wrote: >Thus the big question: why does the RIPE NCC allow that junk to exist >there? (Noting that it was shown last year that that "organisation" >inserted bogus stuff too... and it has not been resolved) That is indeed the Big Question. What is the answer? I am seriously asking. I also am aware of at least one very large clump of IPv4-related "pollution" within the RIPE data base... about which I will say more soon (although as far as I can tell, nobody on -any- of the RIPE mailing lists gives a damn about such things)... and I also wonder why no one seems to care about all of the blatantly bogus pollution in the RIPE data base. I can only guess that the answer to that probably has a lot to do with money, one way or another. covfefe

1 0

Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Jeroen Massar 19 Jun '17

19 Jun '17

TLDR: - SixXS inet6nums will be cleansed out from RIPE DB - Somebody has 400k junk inet6nums (40% of total) in there... Hola, In regards to https://www.sixxs.net/sunset/, a few hours ago I let our little robot do one last chore: remove all SixXS inet6num's from the RIPEdb as those prefixes are now unused and if any abuse claims where outstanding (we didn't receive any over the last multiple years actually) then those folks had enough time to whois them... Normally, that robot was responsible for ensuring that all tunnels & subnets where properly registered in the database and also removed when they where not used (marked deleted) by that user for two weeks. I now instructed it to consider all prefixes (tunnels and subnets) as deleted and then let it batch out the changes (the RIPE mailserver does not like very large mails it seems...). It is already taking a few hours, but it seems that the mails that where sent in a period of 9 minutes, are being processed slowly, as responses of the updates are coming in. I am looking forward to the graph updating: https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates to see how much impact it had, as it seems that it is very slow... # Some stats Some stats, the robot takes: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz $ cat ripe.db.inet6num |grep "^inet6num:" | wc -l 1000583 (that number is way too high, see below for why) 13 years ago in 2004 I wrote: https://www.ripe.net/ripe/mail/archives/db-wg/2004-May/002728.html "Thus SixXS takes care of 53.98% of the inet6num's" when we had 2898 prefixes ;) This time the robot found 70581 prefixes to clean (quite a few have been wiped already in the last months btw, thus that was not the max number, just the ones still left ;) Tomorrow all these SixXS prefixes should be gone. According to that number, SixXS would be 7% of the prefixes, that is rather quite a different number, thus I wondered, why is that. # Why are there now 1 million inet6nums? Junk! Thus lets look at the prefixes with more than 10k inet6nums registered: $ cat ripe.db.inet6num.clean | grep "^inet6num:" | awk '{print $2}' | cut -f1,2 -d: | sort -n |uniq -c | sort -n ... 10575 2001:6f8 <---- Easynet, mostly SixXS prefixes 13675 2001:4dd0 <---- Netcologne, mostly SixXS 14038 2001:41f0 <---- Ziggo, wow! now to actually enable users... 33982 2a02:1630 <---- AS30848 "TWT Spa" in .it nice! 37372 2a00:2381 <---- British Telecom nice! 61500 2a07:7ec4 <---- vv junk registrations 61501 2a07:7ec2 64575 2a07:7ec1 64575 2a07:7ec5 64577 2a07:7ec0 65600 2a07:7ec3 65600 2a07:7ec6 65600 2a07:7ec7 <---- ^^ junk registrations 210219 2a01:4f8 <---- Hetzner (makes sense to me...) So apparently, somebody who is not a LIR and who was last year caught with inserting bogus entries: https://www.ripe.net/ripe/mail/archives/db-wg//2016-May/005264.html currently has !!!!~400k!!!! inet6nums in there, that is ~40% of the total!!!! I picked a random few, most of them do not appear to actually be routed. If you look at the contents, you also notice that the details are bogus. Thus the big question: why does the RIPE NCC allow that junk to exist there? (Noting that it was shown last year that that "organisation" inserted bogus stuff too... and it has not been resolved) On top of that those 400k++ inet6nums all show bogus geo location (and are generally useless as they do not contain info at all), lets look at what registers that: inet6num: 2a07:7ec0::/29 netname: NL-OSP-20160517 country: GB ... address: Spuistraat 249-II address: 1012VP Amsterdam ... org-type: OTHER ... Really, a Dutch address, claiming a British country, while the prefix clearly show "NL" as prefix. Website at http://www.onlineserviceproviderbv.nl/ is empty, hosted on throw-away Digital Ocean, not on "own" infrastructure (the prefixes they have..). Checking RIS: https://stat.ripe.net/2a07%3A7ec0%3A%3A%2F29#tabId=routing Next to storing junk in RIPEDB, apparently also wasting a lot of routing space, as they all end up in a land of randomness. As that office address is close by RIPE NCC, can somebody maybe visit them and try to educate these folks (if anybody is there), to become quite a bit better netizen.... though, I bet you'll find people more home at: aut-num: AS202792 as-name: CLOUDSRV ... org-name: CloudSRV Limited org-type: LIR address: Unit 24 Oakleigh Court, Church Hill Road address: EN4 8UX address: East Barnet address: UNITED KINGDOM who are announcing a /31 of that space... I guess that after all these years it is still a very good idea to apply: https://www.space.net/~gert/RIPE/ipv6-filters.html Greets, Jeroen

1 0

Launching My Resources in the RIPE Database
by Alex Band 08 Jun '17

08 Jun '17

Dear colleagues, We are pleased to announce My Resources, a new service in the RIPE Database that allows resource holders and members who sponsor resources to get a comprehensive overview of all IPv4, IPv6 and ASN resources they hold or sponsor at a glance. Resource holders can also manage their resources with an easy-to-use inline editor. For more information, please see the news announcement: https://www.ripe.net/manage-ips-and-asns/db/announcements/launching-my-reso… Kind regards, Alex Band Product Manager RIPE NCC

1 0

AS34991 -- hijacked
by Ronald F. Guilmette 06 Jun '17

06 Jun '17

Is there any chance that any of you might be persuaded to have a word or two with either or both of the upstreams for AS34991, specifically with respect to the fact that that whole and entire AS has quite obviously been hijacked, and that it is currently being used and abused to announce a total of 20 completely and transparently bogus routes into various bits of IPv4 space that are allocated to various parties within the nation of Columbia, including but not limited to the National University thereof? I have already attempted to make contact with both upstreams in this case with no success and no reply so far, perhaps because I am not a european, or perhaps because I myself am not a network operator, or perhaps because I do not speak (or write) bulgarian. Below is a listing of the currently hijacked routes. Please note that the hijacker in this case quite obviously planned this all, quite carefully, and in advance of the actual hijackings, and he tried (and succeded!) to effectively legitimize all of these bogus route announcement via the simple and easy ruse of also pre-creating a set of matching, and equally bogus route objects within the RIPE data base. (As I learned the last time a case like this came up, the RIPE community, in its infinite wisdom, had made it so easy to create such route objects in the data base, with no authority or authorization whatsoever, that any baboon with a keyboard and a pulse may easily do so.) Of course, as the more observant among you may note, the domain name used for the contact email address for AS34991 has recently been re-registered, presumably after having lapsed. This indicates rather clearly, I think, that it is not merely the IPv4 blocks listed below that have been and are being hijacked, but also the AS34991 ASN itself. covfefe P.S. For the record, yes, some of the hijacked blocks in this case have already been sub-leased out to snowshoe spammers, and are being actively used for snowshoe spamming as we speak. ===================================================================== 152.204.132.0/24 -- Columbia 152.204.133.0/24 -- Columbia 152.231.25.0/24 -- Columbia 152.231.28.0/24 -- Columbia 168.176.187.0/24 -- Columbia, National University of 168.176.192.0/24 -- Columbia, National University of 168.176.194.0/24 -- Columbia, National University of 168.176.218.0/24 -- Columbia, National University of 168.176.219.0/24 -- Columbia, National University of 179.1.71.0/24 -- Columbia 181.57.40.0/24 -- Columbia 186.113.13.0/24 -- Columbia 186.113.15.0/24 -- Columbia 186.147.230.0/24 -- Columbia 190.90.31.0/24 -- Columbia 190.90.88.0/24 -- Columbia 200.1.65.0/24 -- Columbia 200.14.44.0/24 -- Columbia 200.24.3.0/24 -- Columbia 200.24.5.0/24 -- Columbia

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Adam Castle 29 May '17

29 May '17

Hello Elvis, Thanks for your comments. The RIPE NCC, with input from the working group chairs, are currently investigating a solution for all of the RIPE community mailing lists, which we hope will have as little negative impact as possible on those users who do not have DMARC enabled. We are hoping to have this solution tested and rolled out on all of our managed lists as soon as we can and we appreciate your patience in the meantime. Many thanks, Adam Castle Web Services RIPE NCC >> *From: *Elvis Daniel Velea <elvis(a)velea.eu <mailto:elvis@velea.eu>> >> *Subject: **Re: [db-wg] Whois release 1.89 deployed to the Release >> Candidate Environment* >> *Date: *24 May 2017 at 18:23:16 GMT+2 >> *To: *Tim Bruijnzeels <tim(a)ripe.net <mailto:tim@ripe.net>> >> *Cc: *db-wg(a)ripe.net <mailto:db-wg@ripe.net> >> >> Hi Tim, >> >> I can not believe that you guys still can not fix the mailing list to >> show the e-mails correctly. >> >> They currently (for the past few months) appear on an iPhone as attached : >> >> >> >> elvis >> >> Excuse the briefness of this mail, it was sent from a mobile device. >> >>> On May 24, 2017, at 06:38, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net >>> <mailto:db-wg@ripe.net>> wrote: >>> >>> <mime-attachment> >

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Gert Doering 24 May '17

24 May '17

Hi, On Wed, May 24, 2017 at 06:23:34PM +0200, Elvis Daniel Velea via db-wg wrote: > I can not believe that you guys still can not fix the mailing list to show the e-mails correctly. Thank the people that invented DMARC, consciously breaking mailing lists, and declaring that "not our problem". (But the NCC is working on other options) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Elvis Daniel Velea 24 May '17

24 May '17

Hi Tim, I can not believe that you guys still can not fix the mailing list to show the e-mails correctly. They currently (for the past few months) appear on an iPhone as attached : elvis Excuse the briefness of this mail, it was sent from a mobile device. > On May 24, 2017, at 06:38, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > <mime-attachment>

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Tim Bruijnzeels 24 May '17

24 May '17

Dear working group, We are working on an impact analysis for this NWI and we expect to have a response within two weeks. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Tim Bruijnzeels 24 May '17

24 May '17

Dear Working Group, We found two minor issues while 1.89 was in the Release Candidate Environment. #1 Abuse contact information was sometimes returned incorrectly for ASNs #2 The “Zonemaster” configuration was incorrect We had a fix ready for the first issue and therefore we deployed release 1.89.1 to production on 22 May as planned. The fix for the second issue was deployed on 23 May. Note that “Zonemaster” is not enabled yet in production. Although this was tested in the Release Candidate environment, and we don’t expect issues, we plan to enable “Zonemaster” in production manually, knowing that we have the option to revert without the need for a new release in case unforeseen issues are still found. We will send an announcement about this change to this working group before we do. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 May 2017, at 14:55, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > > From: Tim Bruijnzeels <tim(a)ripe.net> > Subject: Whois release 1.89 deployed to the Release Candidate Environment > Date: 4 May 2017 at 14:55:51 GMT+2 > To: db-wg(a)ripe.net > > > Dear working group, > > We just deployed release 1.89 to the Release Candidate (RC) environment. If no issues are raised we plan to deploy this version to production on 22 May 2017. > > This release contains a number of small improvements: > > - Include information on who changed an object in update responses if SSO or PGPKEY is used for authentication > - Replaced dnscheck with Zonemaster for improved domain object (and nameserver) validation > - Fixed NRTM client bugs #279 and #294 > > The complete list of other minor issues solved by this release can be found here: > https://github.com/RIPE-NCC/whois/blob/master/changes.txt > > Kind regards > > Tim Bruijnzeels > Assistant Manager Software Engineering > RIPE NCC Database Group > > >

1 0

NWI-7: abuse-c implementation request
by William Sylvester 22 May '17

22 May '17

DB-WG Members, Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. 5) Clean up data relating to the deprecated attributes. 6) Update the 'person' keyword to take account of "abuse-c:" Thank you all for your work on this proposal! Kind regards, William on behalf of DB-WG co-chairs

1 0

First RIPE NCC webinar for law enforcement
by Richard Leaning 17 May '17

17 May '17

Hi all, Some of you are aware that the RIPE NCC has been actively engaging with law enforcement across Europe to help them gain a better understanding of RIPE NCC tools and services that might be of use in cybercrime investigations - including the RIPE Database. After the discussion that took place during the Database Working Group session at RIPE 74 last week (https://ripe74.ripe.net/programme/meeting-plan/db-wg/<https://ripe74.ripe.net/programme/meeting-plan/db-wg/), I thought some of you might be interested in learning about a new initiative by the RIPE NCC, in collaboration with Europol and CEPOL (the European Union Agency for Law Enforcement Training), to offer a series of six webinars tailored specifically to police, law enforcement and judiciary working in the area of cybercrime. The first of these took place on 15 May, with more than 400 cybercrime agents participating from across Europe: https://www.ripe.net/publications/news/ripe-ncc-webinars-for-law-enforcement We’ll publish a more detailed article on RIPE Labs when the webinar series concludes next month. Kind regards, Richard Leaning External Relations RIPE NCC

1 0

DB accuracy
by denis walker 11 May '17

11 May '17

Hi I can't connect to the chat at the meeting but I would like to say the definition of the country attribute has come up many times over the years and never been sorted out...a good example of what I was talking about. cheersdenis co-chair DB-WG

1 0

Whois release 1.89 deployed to the Release Candidate Environment
by Tim Bruijnzeels 04 May '17

04 May '17

Dear working group, We just deployed release 1.89 to the Release Candidate (RC) environment. If no issues are raised we plan to deploy this version to production on 22 May 2017. This release contains a number of small improvements: - Include information on who changed an object in update responses if SSO or PGPKEY is used for authentication - Replaced dnscheck with Zonemaster for improved domain object (and nameserver) validation - Fixed NRTM client bugs #279 and #294 The complete list of other minor issues solved by this release can be found here: https://github.com/RIPE-NCC/whois/blob/master/changes.txt Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Sander Steffann 24 Apr '17

24 Apr '17

Hi, > I do listen to your one voice Gert. Now with Sebastian at least we have two voices. Please, consensus != number of voices. I fully agree with Gert and I have kept quiet because he worded the objections so well. If it's number of voices you want, count me in. Cheers, Sander

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Randy Bush 22 Apr '17

22 Apr '17

>> are we really spending time discussing how many iterations of irr >> object search we will perform to find an email address of an abuse >> contact to which we can send email which will be ignored? :)/2 > > There are those that actually do read their incoming abuse reports, > and that care to direct those properly for the resources they have > taken stewardship. yes, we are all self-righteous upstanding netizens here. all .01% of us. all i get at the abuse address is spam. randy

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Randy Bush 21 Apr '17

21 Apr '17

are we really spending time discussing how many iterations of irr object search we will perform to find an email address of an abuse contact to which we can send email which will be ignored? :)/2 randy

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Bengt Gördén 21 Apr '17

21 Apr '17

At 2017-04-21 kl. 14:34, denis walker said to db-wg: > Hi Gert > > I do listen to your one voice Gert. Now with Sebastian at least we > have two voices. Unfortunately, the way this community works that is > probably the only consensus we will get to move forward. It is by no > means representative, but it is a consensus. Now you are jumping to conclusions. I carefully read the list and the contribution that concerns me. Just because people stay silent doesn't mean they do or don't agree. Usually the contributors to the discussion have already come up with intelligent comments and I (and probably most of us) don't need to add more to it until the voting. But if you really need a +1, I'm with Gert Doering and David Hilario on this. Now we wait for the voting. Cheers, -- Bengt Gördén Resilans AB

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Tim Kleefass 21 Apr '17

21 Apr '17

On 21.04.17 15:05, Bengt Gördén via db-wg wrote: > But if you really need a +1, I'm with Gert Doering and David Hilario on > this. +1 Cheers, Tim

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Sebastian Wiesinger 21 Apr '17

21 Apr '17

* denis walker via db-wg <db-wg(a)ripe.net> [2017-04-20 13:35]: > Date: Thu, 20 Apr 2017 11:34:22 +0000 (UTC) > From: denis walker <ripedenis(a)yahoo.co.uk> > To: Sebastian Wiesinger <sebastian(a)karotte.org>, "db-wg(a)ripe.net" > <db-wg(a)ripe.net> > Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems > Reply-To: denis walker <ripedenis(a)yahoo.co.uk> > Message-ID: <1214539347.1395203.1492688062209(a)mail.yahoo.com> > X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Macintosh; Intel > Mac OS X 10.7; rv:48.0) Gecko/20100101 Firefox/48.0 > > Hi Sebastian > Thanks for the comments. This proposal is just an idea that would > preserve some of the benefits of the "abuse-c:" design, but I am not > going to push hard for it. However, let me at least clear up some of > the points you made. (Sorry for it all being top posted but yahoo > doesn't allow for inline comments.) Hi Denis, sorry I'm having a really hard time reading your mails, I have to do extensive reformatting. Could you perhaps use a mail client that doesn't produce a wall of text? > We already have "sponsoring-org:", so a "contact-org:" would be fine. Why is having three fields named *some*-org better than two? That the field is called contact-org or abuse-c or abuse-mailbox should not matter, right? > Indirection and inheritance can sometimes involve complexity at the > raw data level, but all of that complexity can be hidden behind > simple to use tools. So I don't think that in itself is a show > stopper. Will you build the tools so that everyone can use them? If you can build tools you can work around almost anything but I'm thinking about people who edit the object on the webportal to add an abuse contact or send it to the mail interface. > "Instead just adding an "abuse-c:" field to an object is easily > understandable."I agree this is easily understandable. But it breaks > one of the principles of the "abuse-c:" design...the "abuse-c:" > attribute only exists in one place, the ORGANISATION object. Now it > will be in four object types...ORGANISATION, INETNUM, INET6NUM, > AUT-NUM. Before we implemented "abuse-c:" the "abuse-mailbox:" > attribute was allowed in five object types...PERSON, ROLE, MNTNER, > ORGANISATION, IRT. This created the mess that lead to the design of > "abuse-c:" But if this is the way we go forward then we can avoid > previous pitfalls with good management tools. What management tools do you mean? Every LIR would have to implement these if we don't make it easy enough to use it by hand. In my mind the goal is to add the attribute at the level it is used and that would be inet(6)num and maybe autnum. This was not done before. > I think you misunderstood the point about email being (in)sufficient > information. I agree almost all abuse reports come via email. My > point was, what happens if the complainant gets no response to the > email complaint? If the email address is all the information they > have, then they hit a brick wall. They don't know what organisation, > company, individual sits behind that email address. But again, if > this is the way we move forward then we have to put our business > analyst and software engineering hats on and solve the problem by > providing better information to consumers of this data. If the complaint gets no response by mail then most people will not go further anyway. What good would it do them to know which person or company sits behind that mailadress? They didn't get a response. *If* they want to dig deeper they can still look at the org object or admin/tech contacts and so on. > We will accept the consensus view of the community in these talks. > If there is a clear consensus to add "abuse-c:" to resource objects, > that is what we will ask the RIPE NCC to implement. At least that would be my preferred solution if noone has a simpler one. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by denis walker 21 Apr '17

21 Apr '17

Hi Gert I do listen to your one voice Gert. Now with Sebastian at least we have two voices. Unfortunately, the way this community works that is probably the only consensus we will get to move forward. It is by no means representative, but it is a consensus. cheers denis co-chair DB-WG From: Gert Doering via db-wg <db-wg(a)ripe.net> To: Sebastian Wiesinger <sebastian(a)karotte.org> Cc: db-wg(a)ripe.net Sent: Friday, 21 April 2017, 13:59 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems Hi, On Thu, Apr 20, 2017 at 11:47:37AM +0200, Sebastian Wiesinger via db-wg wrote: > Denis wrote: > > There is also a question over the double indirection to get to the > > abuse contact information, ie resource object -> ORGANISATION object > > -> ROLE object. I'm not sure how many times I've stated this in the past: this double indirection looks great in computer science theory, but it annoys real people enough to just not jump through these hoops - so "nothing is done, because it is too annoying". I'm among this group. If I have to create (and maintain) an extra organization: object just to be able to point a more-specific inetnum to a different abuse-c: (or just add a more-specific abuse-mailbox:) - then I'm just not going to do it. Not sure what's so hard in *listening*, and then coming up with a solution that takes the statements said into account, not "make a beautiful database out of it" - to make this work, it needs to be easy on people that *do* the work, not pretty on the back side. [..] > I think it is a show stopper. You have to understand the logic and > implement the tools. Many LIRs will shy away from that. Instead just > adding an "abuse-c:" field to an object is easily understandable. This! > To sum it up, I don't think that this approach will make it easier to > add and maintain abuse information in the database and as such will > not improve the goal of having accurate and up-to-date abuse contact > information. I would not support the proposal in this form. And this! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Gert Doering 21 Apr '17

21 Apr '17

Hi, On Thu, Apr 20, 2017 at 11:47:37AM +0200, Sebastian Wiesinger via db-wg wrote: > Denis wrote: > > There is also a question over the double indirection to get to the > > abuse contact information, ie resource object -> ORGANISATION object > > -> ROLE object. I'm not sure how many times I've stated this in the past: this double indirection looks great in computer science theory, but it annoys real people enough to just not jump through these hoops - so "nothing is done, because it is too annoying". I'm among this group. If I have to create (and maintain) an extra organization: object just to be able to point a more-specific inetnum to a different abuse-c: (or just add a more-specific abuse-mailbox:) - then I'm just not going to do it. Not sure what's so hard in *listening*, and then coming up with a solution that takes the statements said into account, not "make a beautiful database out of it" - to make this work, it needs to be easy on people that *do* the work, not pretty on the back side. [..] > I think it is a show stopper. You have to understand the logic and > implement the tools. Many LIRs will shy away from that. Instead just > adding an "abuse-c:" field to an object is easily understandable. This! > To sum it up, I don't think that this approach will make it easier to > add and maintain abuse information in the database and as such will > not improve the goal of having accurate and up-to-date abuse contact > information. I would not support the proposal in this form. And this! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by David Hilario 21 Apr '17

21 Apr '17

Hi Denis, On Thursday, April 20, 2017, 7:34:50 PM GMT+8, denis walker via db-wg <db-wg(a)ripe.net> wrote: > I think you misunderstood the point about email being (in)sufficient information. I agree almost all abuse reports come via email. My >point was, what happens if the complainant gets no response to the email complaint? If the email address is all the information they >have, then they hit a brick wall. They don't know what organisation, company, individual sits behind that email address. But again, if this >is the way we move forward then we have to put our business analyst and software engineering hats on and solve the problem by >providing better information to consumers of this data. To be fair, no one can actually tell who should be contacted as the "abuse" can be of so many kinds, the definition of abuse itself never even reached any firm definition I believe. Who should be contacted, in a somewhat relevant order: The registration information in the Assignment itself? The registration information in any intermediate layer found between an assignment and an allocation? The LIR that issued the Assignment? The sponsoring LIR, in case of PI? The AS announcing the space? The sponsoring LIR of the AS number announcing the space? The peering AS numbers? The RIPE NCC? The other RIRs?**end of RIPE Database scope of information**For other RIRs, repeat all of the above and add NIRs for some of them just to get extra complexity for everyone... Their local LEAs? >From either policy, Database or real life point of view, all the above are valid contacts and can be relevant in reporting abuse depending on its nature. So other than allowing/enabling an easy way for RIPE Database users that want clear ways of getting abuse report and to get that registered and displayed on queries, I don't believe it is in the power of anyone to guess where the abuse report should go. When a user does not understand hierarchical delegation queries the Database, they also probably have no clue of route announcements, sponsoring LIRs, RIR system and so on, the educational part will be quite big then. I do believe that that educational information part can be made available in a simple language so that the ones who really care, can learn and crawl through the complex hierarchy and policies and the others will just give up or contact someone they know to do it for them. Keep in mind as well that no DB data input policy or rules will ever make the "abuser" care about any reports they might receive, this discussion is only for the people who care about receiving reports, it would help a bit for the ones reporting when getting in touch with good networks and will have no effects ion reporting to "abusers" on bad networks. On the proposed solution with contact-org, one of the main complaints was the need to create an org Object per abuse-email, it is not alleviating that issue. Let's not make the life of good network harder, it should be simple to manage these contact details, have an abuse-mailbox: added to inetnum could be a simple solution, LIR portal gives you an overview of all your registered objects primary keys and the abuse email linked to them. If you want to change that, click edit/restore default/add and change the email, the first time that you replace the default value a small pop-up informing you that an abuse-mailbox: will be added to the object to replace the default abuse-c: value, done. No need to learn a new Org object hierarchy or how to make mass updates to the RIPE Database to change the abuse email for your cloud services and keep the "old" abuse email for your ISP services. People who would prefer to do this via email/sync/webupdate, can still do it as well, no problem, it isn't breaking any systems. Does anyone know if PI holders have access to an LIR portal like system? Cheers David Co-chair DB-WG From: Sebastian Wiesinger via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Thursday, 20 April 2017, 11:47 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems * denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > It's clear from the problem statement that some situations cannot be > handled with the current arrangement. Mainly because it would > require a reference to a second ORGANISATION object from a resource > object. This is not possible with the syntax and business rules in > the database. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > There is also a question over the double indirection to get to the > abuse contact information, ie resource object -> ORGANISATION object > -> ROLE object. If it is accepted that an email on it's own is not > sufficient information and the clear link to the organisation with > responsibility for handling abuse is also required, then this double > indirection is needed. With the right tools it's easy to manage this > data. This point is not a technical or operational show stopper. > It's more about who needs what information and how do they get it. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by denis walker 20 Apr '17

20 Apr '17

Hi Sebastian Thanks for the comments. This proposal is just an idea that would preserve some of the benefits of the "abuse-c:" design, but I am not going to push hard for it. However, let me at least clear up some of the points you made. (Sorry for it all being top posted but yahoo doesn't allow for inline comments.) We already have "sponsoring-org:", so a "contact-org:" would be fine. Indirection and inheritance can sometimes involve complexity at the raw data level, but all of that complexity can be hidden behind simple to use tools. So I don't think that in itself is a show stopper. "Instead just adding an "abuse-c:" field to an object is easily understandable."I agree this is easily understandable. But it breaks one of the principles of the "abuse-c:" design...the "abuse-c:" attribute only exists in one place, the ORGANISATION object. Now it will be in four object types...ORGANISATION, INETNUM, INET6NUM, AUT-NUM. Before we implemented "abuse-c:" the "abuse-mailbox:" attribute was allowed in five object types...PERSON, ROLE, MNTNER, ORGANISATION, IRT. This created the mess that lead to the design of "abuse-c:" But if this is the way we go forward then we can avoid previous pitfalls with good management tools. I think you misunderstood the point about email being (in)sufficient information. I agree almost all abuse reports come via email. My point was, what happens if the complainant gets no response to the email complaint? If the email address is all the information they have, then they hit a brick wall. They don't know what organisation, company, individual sits behind that email address. But again, if this is the way we move forward then we have to put our business analyst and software engineering hats on and solve the problem by providing better information to consumers of this data. Bottom line....it is the intention of the DB-WG co chairs to resolve the issues stated in the problem statement on this round of talks. We will accept the consensus view of the community in these talks. If there is a clear consensus to add "abuse-c:" to resource objects, that is what we will ask the RIPE NCC to implement. I just want to be sure people understand the issues, both operational and technical, before making their decision. Once the decision is made, if there are other issues that may come up as a consequence, then we will solve those issues....but we must move this problem towards a resolution this time. cheers denis co-chair DB-WG From: Sebastian Wiesinger via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Thursday, 20 April 2017, 11:47 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems * denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > It's clear from the problem statement that some situations cannot be > handled with the current arrangement. Mainly because it would > require a reference to a second ORGANISATION object from a resource > object. This is not possible with the syntax and business rules in > the database. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > There is also a question over the double indirection to get to the > abuse contact information, ie resource object -> ORGANISATION object > -> ROLE object. If it is accepted that an email on it's own is not > sufficient information and the clear link to the organisation with > responsibility for handling abuse is also required, then this double > indirection is needed. With the right tools it's easy to manage this > data. This point is not a technical or operational show stopper. > It's more about who needs what information and how do they get it. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Sebastian Wiesinger 20 Apr '17

20 Apr '17

* denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > It's clear from the problem statement that some situations cannot be > handled with the current arrangement. Mainly because it would > require a reference to a second ORGANISATION object from a resource > object. This is not possible with the syntax and business rules in > the database. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > There is also a question over the double indirection to get to the > abuse contact information, ie resource object -> ORGANISATION object > -> ROLE object. If it is accepted that an email on it's own is not > sufficient information and the clear link to the organisation with > responsibility for handling abuse is also required, then this double > indirection is needed. With the right tools it's easy to manage this > data. This point is not a technical or operational show stopper. > It's more about who needs what information and how do they get it. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0