- db-wg - mailman.ripe.net

DMARC issue
by denis walker 23 Mar '17

23 Mar '17

Colleagues The RIPE NCC has applied a mailman work around for DMARC to the DB-WG mailing list. This effectively wraps the sender inside the list address. The only real significance of this is that if you hit Reply the mail goes to the list and not the original sender. So if you want to send a private comment back to the original sender 'off list' you need to either hit Reply All and delete the addresses you don't want or Forward it. cheersdenisco-chair DB-WG

2 2

Re: [db-wg] DMARC issue
by denis walker 23 Mar '17

23 Mar '17

Actually Reply does still work and sends the mail back to the original sender. It does set the Reply-To correctly. I successfully received this post on my yahoo, gmail and xs4all accounts. So from now on no list member's email provider should reject posts to the DB-WG because of DMARC policies. cheersdenisco-chair DB-WG From: denis walker via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Thursday, 23 March 2017, 12:58 Subject: [db-wg] DMARC issue Colleagues The RIPE NCC has applied a mailman work around for DMARC to the DB-WG mailing list. This effectively wraps the sender inside the list address. The only real significance of this is that if you hit Reply the mail goes to the list and not the original sender. So if you want to send a private comment back to the original sender 'off list' you need to either hit Reply All and delete the addresses you don't want or Forward it. cheersdenisco-chair DB-WG

1 0

test message - please ignore
by denis walker 22 Mar '17

22 Mar '17

Apologies for sending this message out but we need to check some issues with the DB-WG mailing list. cheersdenisco-chair DB-WG

1 0

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