- db-wg - mailman.ripe.net

Re: [db-wg] RIPE database on ftp.ripe.net
by Paul Weiss 08 May '18

08 May '18

Hi Marten, In the directory https://ftp.ripe.net/ripe/dbase/split/ <https://ftp.ripe.net/ripe/dbase/split/> there are lots of "splits", is there an inventory guide so that we can understand which type of data each split contains? We need to access and search for; Company name, Org.number, Country, City, IP-range Can we also ftp download the complete IP Databases per country in Europe? Thanks, Paul Weiss

2 1

Re: [db-wg] Draft Agenda RIPE76 - Database Working Group
by William Sylvester 26 Apr '18

26 Apr '18

Dear all, Below is the agenda for the Database Working Group for RIPE76. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 20 mins Tim Bruijnzeels, RIPE NCC C. Current State of RDAP - 20 mins Andrew Newton, ARIN D. General Data Protection Regulation (GDPR) - 10 mins Maria Stafyla, RIPE NCC E. A modern chatbot approach for accessing RIPE database - 10 mins Laurenz Wagner, Janus Cloud F. NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation - 5 mins G. NWI - Open Proposals - 10 mins Z. AOB (open discussion)

1 0

Draft Agenda RIPE75 - Database Working Group
by William Sylvester 17 Apr '18

17 Apr '18

Dear all, Below is the draft outline for the Database Working Group agenda for RIPE76. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 40 mins Tim Bruijnzeels, RIPE NCC C. NWI - Open Proposals - 10 mins D. General Data Protection Regulation (GDPR) - 10 mins Maria Stafyla, RIPE NCC Z. AOB (open discussion)

1 0

Updating the database via HTTP API - best practices
by Alexander Stranzky 12 Apr '18

12 Apr '18

> What is the current best practice for handling Auth on HTTP API updates to the RIPE database, and is there a roadmap for change that I can consider as I write my tools to publish and maintain objects? Same situation here on my end. Anyways, I'd love to have an authentication method that uses one of my existing RIPE DB key-cert objects (maybe something like an HMAC). 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

1 0

Updating the database via HTTP API - best practices
by Andy Davidson 11 Apr '18

11 Apr '18

Hi, I would like to publish information in the RIPE database based on what my single-source-of-truth configuration management system knows and not what I sort of remember when I kind of get around to updating RIPE. Fortunately, there is a splendid looking API for this. The most recent and complete documentation that I can find with support from a search engine is https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API. On the subject of Authentication, the document says: "Currently only passwords are supported to authenticate updates”. Is this still up to date and entirely true? Does it mean MD5 password or does this mean I should be able to use something based on my SSO authentication pair to generate a password field? I thought that MD5 had been deprecated in circa. 2015? https://www.ripe.net/ripe/mail/archives/db-wg/2015-June/004666.html What is the current best practice for handling Auth on HTTP API updates to the RIPE database, and is there a roadmap for change that I can consider as I write my tools to publish and maintain objects? Thanks for your help, database-wg & NCC experts, Andy -- Andy Davidson Asteroid International BV https://www.asteroidhq.com @asteroidhq @andyd -------------------------------------------------- Local interconnection. Where you need it.

1 0

Getting fraudulent entries removed
by Brian Rak 07 Apr '18

07 Apr '18

Hi, We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue) What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523) The fraudulent entry is: https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19A… route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well. You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1 Thanks, Brian Rak

6 13

Getting 'responsible organization' out of RDAP
by Brian Rak 22 Mar '18

22 Mar '18

I've been attempting to use RDAP to verify our customer's IP information, however I'm running into some difficulties due to differences between ARIN's implementation and RIPE's. For example, I'm trying to get the organization name for a particular IP. On ARIN, this is easy. I look through the provided vcards for one where the kind is 'org', and that gives me the information about the organization. (ex: https://rdap.arin.net/registry/ip/66.55.158.27 ) With RIPE's RDAP implementation, this data does not seem to be readily available. For example, if I look at https://rdap.db.ripe.net/ip/195.66.225.160 I'd expect to find the string 'London Internet Exchange Ltd.' somewhere within the response. If I look at the web UI: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=195.66.225.160#result… , this information is easily available. Would it be possible to expand the RDAP results to include organization information? This seems like it would just be another vcard entry, so there really shouldn't be any backwards compatibility issues. Apologies if this isn't the correct list, I can't really find any information about RDAP on RIPE's website.

3 6

Whois Update Server Migration
by Edward Shryane 21 Mar '18

21 Mar '18

Dear Working Group, on Wednesday 21st March, we plan to migrate the Whois Update Server to a new configuration. This will cause a short downtime for Whois updates. Queries will not be affected. We will also create a Service Announcement on the RIPE NCC website. Regards, Ed Shryane RIPE NCC

2 4

Whois release 1.91 in Release Candidate environment, production release planned for 7th March
by Edward Shryane 14 Mar '18

14 Mar '18

Dear Working Group, RIPE Database release 1.91 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on 7th March. Release 1.91 includes the following main changes : - Removed "abuse-mailbox:" attribute from person,mntner,organisation,irt object types (as part of NWI-7 abuse-c implementation) - Don't allow multiple spaces, tab characters, or multiple lines, in the organisation org-name attribute. - Exclude certain email addresses (such as mailing lists and ticket queues) in abuse-mailbox,e-mail,irt-nfy,mnt-nfy,notify,ref-nfy,upd-to attributes - Added "end of stream" comment to NRTM responses - Fixed inconsistent newlines in --list-versions response The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt Please let us know if you see any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 2

New on RIPE Labs: Legal Grounds for Lawful Personal Data Processing and the RIPE Database (GDPR)
by Athina Fragkouli 06 Mar '18

06 Mar '18

Dear all, In our third article on the GDPR, we are looking at the legal basis for processing personal data in the RIPE Database when it refers to an individual resource holder or contact person. We will also outline the relevant obligations of the responsible parties. https://labs.ripe.net/Members/Athina/gdpr-legal-grounds-for-lawful-personal… Kind regards, Athina Fragkouli Head of Legal RIPE NCC

1 0

NRTM replication inefficiencies
by Job Snijders 21 Feb '18

21 Feb '18

Dear all, There may be some improvement opportunity for NRTMv3. The problem with the RIPE NRTMv2/NRTMv3 format is that it has no 'end-of-stream' indicator, thus making the only way to know that the output has ended (vs. hung/stalled/server dead) is either by observing a time-out & reconnect & compare last serial, or by using single-command connections to the NRTM server - which means even worse performance. When connecting to the RIPE NRTM service and issuing a command like: "-g RIPE:3:11012700-LAST -k" It would be good that when the RIPE NRTM server is done sending its inital blurp of backlogged data, the end of that phase of the stream of objects is marked by the server sending something like: "%CURRENT $TS You are now up to date" ($TS can be a unix timestamp) after this server message the client knows that it can stay connected and that it has received all information so far. I would also welcome an investigation into alternative approaches, (some not-via-WHOIS replication mechanisms), perhaps something over HTTPS can be done? Either way, something more robust would be useful. Kind regards, Job ps. An analogy can be made between BGP route refresh as described in RFC 2918 and Enhanced Route Refresh as described in RFC 7313. One first one didn't have an "End of blurp" marker which negatively impacted its usefulness, the later RFCintroduced the End-of-RIB marker which is very useful.

5 14

Clean up unreferenced maintainers (after 90 days)
by Tim Bruijnzeels 15 Feb '18

15 Feb '18

Dear Working Group, In the light of data protection we already clean up unreferenced organisation, person and role objects, and also mntner-role and mntner-person pairs, 90 days after such objects become unreferenced. So-far unreferenced maintainers are not cleaned up. We have about 8k such objects in the database. These objects are often syntactically incorrect and poorly maintained - so we would like to clean them up automatically 90 days after they become unused. Please let us know if you see any issues with this. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 8

NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
by William Sylvester 14 Feb '18

14 Feb '18

DB-WG Members, Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. This request is to remove “origin:” and flag “route:” objects as specified. 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 solution of NWI-5 as follows: 1) Remove the "origin:" authorization requirement. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. Thank you all for your work on this proposal! Kind regards, William & Denis DB-WG co-chairs

11 21

Implementation of NWI-5 out of region ROUTE(6) objects
by denis walker 12 Feb '18

12 Feb '18

Colleagues Based on the proposal by Tim for NWI-5 and the following discussions, the DB-WG co-chairs would like the RIPE NCC to schedule implementation of the following actions: -Remove the ASN authorisation requirement for ROUTE(6) object creation -Deprecate the "mnt-routes:" attribute in the AUT-NUM object -Remove the 'pending object creation' functionality for route creation -Create the source 'RIPE-NONAUTH' -Move all ROUTE(6) objects relating to non RIPE managed address space to this new source (pending eventual deletion after further discussion) -Move all non ripe managed AUT-NUM objects to this new source (pending eventual deletion after further discussion) -Adjust the query service as suggested in Tim's proposal -Disallow creation of any new AUT-NUM or ROUTE(6) objects in the RIPE Database for non RIPE managed resources, but allow existing objects to be modified or deleted -Remove the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in the RIPE Database for non RIPE managed address space -Delete the MNTNER object with the public password ('fixing' any other database objects that may refer to it) -Update all documentation to reflect the new processes -Ensure that the inter RIR transfer process for resources moving into the RIPE managed address space does not allow the transfer of ROUTE(6) objects from source RIPE-NONAUTH to source RIPE without the agreement of the resource holder cheersDenis & Williamco-chairs DB-WG

1 0

Creation of new out of region ROUTE(6) objects
by William Sylvester 12 Feb '18

12 Feb '18

Working Group Members, Following the last call for comments about creating out of region ROUTE(6) objects in the RIPE Database: https://www.ripe.net/ripe/mail/archives/db-wg/2018-January/005807.html There were a few comments to discontinue this service. There were no comments supporting the continuation of this service. The DB-WG co-chairs therefore draw a consensus on discontinuing this service. William & Denis DB-WG co-chairs

1 0

New on RIPE Labs: How We're Implementing the GDPR - the RIPE Database
by Mirjam Kuehne 01 Feb '18

01 Feb '18

Dear colleagues, This is our second in a series of articles discussing the General Data Protection Regulation (GDPR) implementation. Here we are looking at the purpose for which personal data is collected and publicly accessed through the RIPE Database, as well as other aspects of the data protection legislation, such as the legal basis for this processing, data removal procedures, and so on: https://labs.ripe.net/Members/Athina/how-we-re-implementing-the-gdpr-the-ri… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [db-wg] Chair Selection Process Revision Proposal
by William Sylvester 31 Jan '18

31 Jan '18

WG Members, Based on the working group feedback, we have revised #4 to include the limitation if a chair has been removed. This should resolve any identified concerns. Assuming no further outstanding objections, we can move to establish this as the new process going forward. Kind regards, William & Denis DB-WG Co-Chairs Proposed revision to the Database Working Group chair selection process; 1) Number of chairs is a minimum of 2 with a maximum of 3. 2) Chair can be removed at any time by consensus. 3) Chair terms are staggered yearly. 4) One chair per year is replaced. Any member of the RIPE Community may stand for chair, unless that person has been removed from the position of working group chair in the last 3 years. 5) Working group selects chair by consensus. 6) The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. 7) Selection process is as follow; 7.1) Interested parties have two weeks to make their interest known via the mailing list, or directly to the Chair/s. 7.2) After two weeks, the Chair/s ensure that all candidates are announced on the mailing list and issue a call for discussion. 7.3) WG members express their approval or otherwise of the presented candidates. 7.4) Two weeks after the call for discussion, the Chair/s declare a decision, based on mailing list discussion, as they would do for a policy proposal. 8) Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. 9) In the case more than one chair is up for selection at the same time, the chair with the greatest support will take a multi-year term, the chair with the least support will take the second longest term. Terms will be determined by the number of chairs (3 chairs = 3 year term, 2 chairs = 2 year teams). The intent is to maintain continuity of the working group chairs. So the working group is never left without a chair.

1 0

Re: [db-wg] Chair Selection Process Revision Proposal
by Erik Bais 29 Jan '18

29 Jan '18

Hi William, I would like to support the proposed process. (with the additional clarifications of the remarks of Niall.) If a chair would be removed by consensus, he/she should not be accepted for the same position. Regards, Erik Bais From: db-wg <db-wg-bounces(a)ripe.net> on behalf of William Sylvester via db-wg <db-wg(a)ripe.net> Reply-To: William Sylvester <william.sylvester(a)addrex.net> Date: Monday 11 December 2017 at 18:41 To: Database WG <db-wg(a)ripe.net> Subject: [db-wg] Chair Selection Process Revision Proposal WG Members, At the RIPE75 in Dubai, the working group chairs committed to presenting a proposal for revising the chair selection process and general housekeeping of the Database working group. This was motivated from some of the challenges we experienced as a working group over the past year. After taking a review of the other RIPE community working groups, the proposal below represents what we feel Is a fair approach to revise our current processes. This also includes clarification on matters where previously our processes were unclear. This also includes comments and feedback from members of the working group. Please express your support or otherwise for these changes, the intent is to use this process for future chair selection including the pending selection process due. Kind regards, William & Denis DB-WG Co-Chairs Proposed revision to the Database Working Group chair selection process; 1) Number of chairs is a minimum of 2 with a maximum of 3. 2) Chair can be removed at any time by consensus. 3) Chair terms are staggered yearly. 4) One chair per year is replaced. 5) Working group selects chair by consensus. 6) The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. 7) Selection process is as follow; 7.1) Interested parties have two weeks to make their interest known via the mailing list, or directly to the Chair/s. 7.2) After two weeks, the Chair/s ensure that all candidates are announced on the mailing list and issue a call for discussion. 7.3) WG members express their approval or otherwise of the presented candidates. 7.4) Two weeks after the call for discussion, the Chair/s declare a decision, based on mailing list discussion, as they would do for a policy proposal. 8) Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. 9) In the case more than one chair is up for selection at the same time, the chair with the greatest support will take a multi-year term, the chair with the least support will take the second longest term. Terms will be determined by the number of chairs (3 chairs = 3 year term, 2 chairs = 2 year teams). The intent is to maintain continuity of the working group chairs. So the working group is never left without a chair.

3 2

Chair Selection Process Revision Proposal
by William Sylvester 29 Jan '18

29 Jan '18

WG Members, At the RIPE75 in Dubai, the working group chairs committed to presenting a proposal for revising the chair selection process and general housekeeping of the Database working group. This was motivated from some of the challenges we experienced as a working group over the past year. After taking a review of the other RIPE community working groups, the proposal below represents what we feel Is a fair approach to revise our current processes. This also includes clarification on matters where previously our processes were unclear. This also includes comments and feedback from members of the working group. Please express your support or otherwise for these changes, the intent is to use this process for future chair selection including the pending selection process due. Kind regards, William & Denis DB-WG Co-Chairs Proposed revision to the Database Working Group chair selection process; 1) Number of chairs is a minimum of 2 with a maximum of 3. 2) Chair can be removed at any time by consensus. 3) Chair terms are staggered yearly. 4) One chair per year is replaced. 5) Working group selects chair by consensus. 6) The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. 7) Selection process is as follow; 7.1) Interested parties have two weeks to make their interest known via the mailing list, or directly to the Chair/s. 7.2) After two weeks, the Chair/s ensure that all candidates are announced on the mailing list and issue a call for discussion. 7.3) WG members express their approval or otherwise of the presented candidates. 7.4) Two weeks after the call for discussion, the Chair/s declare a decision, based on mailing list discussion, as they would do for a policy proposal. 8) Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. 9) In the case more than one chair is up for selection at the same time, the chair with the greatest support will take a multi-year term, the chair with the least support will take the second longest term. Terms will be determined by the number of chairs (3 chairs = 3 year term, 2 chairs = 2 year teams). The intent is to maintain continuity of the working group chairs. So the working group is never left without a chair.

4 4

Last Call - creation of new out of region ROUTE(6) objects
by denis walker 11 Jan '18

11 Jan '18

Colleagues Plans to implement the solution for NWI-5 by dropping the auth requirement from ASNs in ROUTE(6) object creation and marking existing out of region ROUTE(6) objects in the database with a different source tag are progressing. In December I asked if we should continue to allow the creation of new ROUTE(6) objects in the RIPE Database (with the new source tag) for non RIPE address space. There were a few comments supporting the view NOT to allow any new object creations. There were no comments supporting the continued creation of any new objects. During the earlier, lengthy discussion on NWI-5 quite a few people supported the use of the RIPE Database for ROUTE(6) objects for non RIPE address space. With the plan to drop the ASN auth requirement are those people satisfied that we no longer need to create these ROUTE(6) objects in the RIPE Database? So basically I am making a last call to see if anyone still feels there is any need to allow creation of any new ROUTE(6) objects in the RIPE Database for non RIPE address space? cheersdenisco-chair DB WG

5 6

Creation of out of region ROUTE(6) objects
by denis walker 14 Dec '17

14 Dec '17

Colleagues We are now approaching the implementation stage for managing the existing out of region ROUTE(6) objects in the RIPE Database (NWI-5). A question has been asked about the creation of new ROUTE(6) objects in the RIPE Database relating to non RIPE address space. This will still be technically possible after implementation of the solution for NWI-5. The question we now need to answer is...Do we want to allow the creation of new ROUTE(6) objects in the RIPE Database for non RIPE address space? Over the years this issue has been debated within this community there have been arguments made for and against this situation. The case against doing this is well known now. If anyone believes there is still a case for allowing these object creations (either for any address space or for some section of the global address space) then can you please make your case now. We would like to wrap up this whole issue with a clear consensus from the community. cheersdenisco-chair DB WG

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Alexander Stranzky 01 Dec '17

01 Dec '17

Am 12.11.17 um 12:00 schrieb db-wg-request(a)ripe.net: > Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the ?org-name:? attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the ?org-name:? matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. While currently not an issue, you should include other non-spaces whitespace (i.e. Tabs & NULL-Bytes) in your blacklist. 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

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Tim Bruijnzeels 23 Nov '17

23 Nov '17

Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 6

Proxy proposal large communities
by Tim Bruijnzeels 14 Nov '17

14 Nov '17

Dear Working Group, As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410 Job is asking to add a “large_community" keyword to RPSL dictionary where applicable. And provides the following example: Suggestion: name the keyword large_community mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER import: from AS35082 95.128.51.234 at 95.128.51.233 action pref=500; large_community.append(29527:0:35082,29527:0:60000,29527:0:61200,29527:0:61210); accept AS-VIBUS-LONDON filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1) From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today. Please discuss. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

5 24

new NWI? - was: mntner object updates by mail
by Piotr Strzyzewski 26 Oct '17

26 Oct '17

Dear WG Members After a nice chat just a seconds after DB-WG session has ended it was brought to the attention of few of us that there was an email sent last December by Ulf Kieber (with some responses) about mntner object updates by mail. Dear Chairs, can we proceed with that and make it next NWI? Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland

5 5