- db-wg - mailman.ripe.net

changes to the implementation of "abuse-c:"
by ripedenis＠yahoo.co.uk 06 Feb '17

06 Feb '17

Colleagues The new co-chairs have prioritized existing and proposed NWIs. Our intent is to reach consensus on open items. We accept that we can't tackle them all at once and we may not address them in numerical order. We would like to start with one that has been discussed for many years, without coming to an acceptable solution, the implementation of the "abuse-c:" attribute. We thoroughly reviewed the working group discussion on the “abuse-c:” attribute, including reviewing Tim's initial draft of a problem statement. We removed the examples to make the problem statement brief and to the point. Anyone concerned with "abuse-c:" has most likely encountered one of these problems and doesn't need quoted examples. We also removed comments on the 'good parts' of the current implementation. That can come back when we discuss pros and cons of possible solutions. Then added in the issue Tobias made about the cleanup. So we end up with the problem statement shown below. Can we agree these are the problems that cause issues with some users? Are there any other problems that anyone has encountered? cheers Denis co-chair DB-WG Problem statement on "abuse-c:" implementation: =============================================== It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation. It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database.

7 11

changes to the implementation of "abuse-c:"
by Alexander Stranzky 17 Jan '17

17 Jan '17

> For a handful of customers that is not difficult, although some still > believe it is over complicated. If you have tens or hundreds of > customers wanting to handle abuse complaints themselves, then it moves > into the 'unreasonable' zone if all this has to be handled manually. For what does the RIPE have a REST API (and programmers that know how to use it)? We have to handle RIPE data for 2K+ customers, without the API that would indeed end in the least possible approach. But there are libraries out there that can be used so we can do abuse handling the intended way (via Org/Role). So maybe we should promote this API (and list client libraries that work with it) way more than today, to tell people that it is not that complicated to get it right. cheers, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

2 1

mntner object updates by mail
by Ulf Kieber 02 Jan '17

02 Jan '17

Dear DB WG members, there currently exists a somewhat tricky deadlock situation in updating mntner objects. Envision the following object: mntner: XOO-MNT admin-c: XOO-RIPE upd-to: kieber(a)xoo.net auth: PGPKEY-B490673F # Ulf Kieber auth: PGPKEY-XXXXXXXX # Somebody Else mnt-by: XOO-MNT source: RIPE Now, XOO is a large, distributed organisation and Someone Else eventually starts adding a bunch of auth: SSO # Filtered None of those SSO accounts is certainly mine. How am I going to update this mntner object without removing those SSO accounts? The issue here is: There is no way of retrieving the SSO account information from the mntner object without an SSO auth on it. Proposal: Add a way to retrieve mntner objects from the DB by encrypted mail (public key PGPKEY-B490673F is already in the database). PS: Mail updates may seem arcane to some, but I've done registry mergers of some 20000 object registries pretty fast that way. Regards, -- Ulf Kieber

4 3

Re: [db-wg] mntner object updates by mail
by Alexander Stranzky 02 Jan '17

02 Jan '17

> Mail updates have 2 reasons to exist: > - massive, bulk updates that would otherwise take too long to execute; > - fire & forget, just send in the update and it would get processed > eventually no matter what. > > In the age of REST APIs, neither of the above stands anymore. > Currently mailupdates is kept as a fallback and/or legacy interface. IIRC, there is an update limit for the current REST API (something like 2000 updates per day) > I think what you really want is being able to authenticate via REST > API, so that you would be able to query and update your own objects > without any kind of dummification or accounting process. Maybe even be > able to use an APIKEY over https for a simple way of authentication? the REST API uses the maintainer password via HTTPS. see also https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API for further details. there are also some client libraries for the REST API out there. Best regards, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

1 0

Reverse DNS Wizard Improvements
by Alex Band 23 Dec '16

23 Dec '16

Dear colleagues, If you don't want to read all the details below, here is a single screenshot that explains the improvements we just launched: https://labs.ripe.net/Members/AlexBand/reverse-dns-real-time-checks A few weeks ago we announced a new wizard for setting up Reverse DNS. When creating a new DOMAIN object you will be taken to it automatically: https://apps.db.ripe.net/webupdates To refresh your memory, a one-minute demo of the wizard is online: https://youtu.be/7JzapYkca-Y After analysing the usage since the launch, we have identified several improvements we could make to the name server pre-checks. I'm happy to announce these are now live. When entering name servers for your reverse zones, we will now do the following real-time checks: - Syntax checks to ensure no illegal characters are used - Verify if a fully qualified domain name is entered and not an IP address - Test if the name server responds on port 53 using both UDP and TCP - Check if the name server is authoritative for the reverse zone Only if these tests are passed the wizard will allow the user to submit the form, after which the full set of checks is performed by the back-end service. By giving immediate feedback, we drastically reduce the amount of errors users generate and the time required to complete the process successfully. In the error messages, we also link to the documentation for an in-depth explanation and troubleshooting steps. We are confident these improvements will greatly enhance the user experience. If you have any questions or feedback, please do not hesitate to let us know! Kind regards, Alex Band Product Manager RIPE NCC

2 1

Thanks to Nigel
by Niall O'Reilly 20 Dec '16

20 Dec '16

On 20 Dec 2016, at 14:42, Piotr Strzyzewski wrote: > Thank you for this hard work. It was always amazing how fast delivered > and accurate your minutes are. It continually amazed me too. Thanks for a great job, Nigel! Niall

1 0

WG Chairs Selection
by ripedenis＠yahoo.co.uk 20 Dec '16

20 Dec '16

Hi All I would like to clarify one point about my candidacy. Whilst it is no secret that I would love to improve the database design and model, that is a personal view and I accept that it is not well supported within the community. There is a time and place for such proposals and this is not the time. The next group of chairs have a growing list of important issues on the table already and that should be the focus. cheersdenis

11 14

Upgrading servers to address memory issues, intermittent outage in mailupdates
by Tim Bruijnzeels 07 Dec '16

07 Dec '16

Dear working group, Following the outage we experienced on 26 November we determined that a an in-memory cache was the cause. We have disabled this cache, and allocated more memory to the whois application process. We also determined that the whois process and the back-end database need more memory. For this reason we are fast-tracking the deployment of new hardware and extending the memory in the servers that we use. Unfortunately the deployment of two new servers led to a failure to deliver some of the mails sent to auto-dbm(a)ripe.net, the Mailupdates service for Whois, from approximately 12:00 UTC on Tuesday 6th December to 16:30 UTC on Wednesday 7th December. Any failure resulted in a reply with the Subject "Mail delivery failed: returning message to sender". Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

WG Chairs Selection
by scott donald 06 Dec '16

06 Dec '16

Hi all, I agree with Nigel that some continuity would be good, so Piotr would get my vote. I also think Denis has deep knowledge of the RIPE Database over many years and his experience would be very useful in the 3 person team. I would also say that David's experience at the RIPE NCC dealing with LIR questions on all aspects of RIPE Database functionality gives him a a very useful insight in how to improve it for the future for the users. Kind regards, Scott Donald Comms-care

2 1

as-set fileds
by Shahin Gharghi 05 Dec '16

05 Dec '16

Hello I was working with RIPE DB to export as-set objects. I downloaded as-set database from FTP server. There were a lot of comments and extra unused information in the members field. So it's difficult to work with this object as a third party software. -- Shahin Gharghi

1 0