- db-wg - mailman.ripe.net

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