- db-wg - mailman.ripe.net

Re: [db-wg] db-wg Digest, Vol 66, Issue 3
by Alexander Stranzky 20 Feb '17

20 Feb '17

> 2. How are updates authenticated? > I'm aware, each object has a "mntner" but how and where is the Maintainer identity part of request to the API? Authentication is done via the maintainer's password. > 3. the Test-DB did not contain any objects related to our company - that's OK. > But could I add them? And how? I guess I may use 'https://apps-test.db.ripe.net/search/lookup.html?source=test&key=TEST-NCC-H…' > Right? There is the test database maintainer (TEST-DBM-MNT) you can use to set up everything using the password "emptypassword". once you have your own maintainer set up, use that one. see also https://github.com/RIPE-NCC/whois/wiki/WHOIS%20REST%20API%20Migration%20Gui… Regards, Alexander Stranzky -- 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

API Documentation
by Andreas Schulze 20 Feb '17

20 Feb '17

Hello, we like to modify RIPE objects using the API under https://rest.db.ripe.net (OK, starting with https://rest-test.db.ripe.net) I found some documentation: - https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-Update - https://www.ripe.net/manage-ips-and-asns/dns/enum/update-enum-delegation But some points are still unclear to me. 1. Is there any documentation about the database definition, which fields an object must or may have? 2. How are updates authenticated? I'm aware, each object has a "mntner" but how and where is the Maintainer identity part of request to the API? 3. the Test-DB did not contain any objects related to our company - that's OK. But could I add them? And how? I guess I may use 'https://apps-test.db.ripe.net/search/lookup.html?source=test&key=TEST-NCC-H…' Right? Thanks for help and nice weekend! Andreas -- A. Schulze DATEV eG

2 2

changes to the implementation of "abuse-c:" - final problem statement
by denis 08 Feb '17

08 Feb '17

1 0

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