- db-wg - mailman.ripe.net

PERSON objects in the RIPE Database
by Alexander Stranzky 21 Sep '18

21 Sep '18

On 20/09/2018 15:04, denis walker via db-wg wrote: > Colleagues, > > I will start with a blunt question, then give some arguments for my > concern. In May the RIPE NCC told me there are?more than 2 million > PERSON objects in the RIPE Database. That is almost 25% of the objects > in the database. Who are these people and why do we hold so much > personal data? Hello, I suspect that many of these objects are old (pre-API) and/or duplicates. Before RIPE had a REST API (and I can't tell how many ISPs still use emails to create their resources) automatically fetching, linking, and updating a RIPE object was a pain (as is the current situation with APNIC) and likely involved someone to create the email personally. Hence going the easy route--making new entries every time. Regards, Alexander Stranzky -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * 63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net

5 7

Re: [db-wg] PERSON objects in the RIPE Database
by Cynthia Revström 20 Sep '18

20 Sep '18

Hi, I am not sure how the best way to do this but maybe check the database for person handles with identical name, address, phone number and such things. Also maybe if we could take a look at the amount of person handles that are not used at all in any other object, and potentially delete them. Kind regards, Cynthia Revström On 2018-09-20 14:57, Alexander Stranzky via db-wg wrote: > On 20/09/2018 15:04, denis walker via db-wg wrote: >> Colleagues, >> >> I will start with a blunt question, then give some arguments for my >> concern. In May the RIPE NCC told me there are?more than 2 million >> PERSON objects in the RIPE Database. That is almost 25% of the objects >> in the database. Who are these people and why do we hold so much >> personal data? > Hello, > > I suspect that many of these objects are old (pre-API) and/or > duplicates. Before RIPE had a REST API (and I can't tell how many ISPs > still use emails to create their resources) automatically fetching, > linking, and updating a RIPE object was a pain (as is the current > situation with APNIC) and likely involved someone to create the email > personally. Hence going the easy route--making new entries every time. > > Regards, > Alexander Stranzky >

2 1

Whois release 1.92.6 deployed to Production
by Edward Shryane 20 Sep '18

20 Sep '18

Dear Working Group, we have deployed a bug-fix release 1.92.6 to production that fixes a bug when updating an object with a lowercase source value (e.g. "source: ripe"). The release notes have been updated: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… Regards Ed Shryane RIPE NCC

1 0

avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
by nusenu 14 Sep '18

14 Sep '18

Dear DB Working Group, when looking into RPKI and RIPE IRR coverage I stumbled on prefixes that are covered by a RIPE route object and a RPKI ROA, which is great, but there are cases where these records make conflicting statements about the origin of a prefix. example: 185.46.20.0/22 origin according to ROA: AS199785 origin according to route object: AS61952 origin according to RIS: AS61952 (matches route object) Note: this is just an example to better illustrate the issue. (I didn't do a comprehensive analysis to be able to tell how often this is the case but for a sample of ~1900 prefixes I found 3 such occurrences.) Since route objects and ROAs are created by the prefix holders this is possible (human mistake). Are there any measures in place to prevent or at least warn about the inconsistency when the IP holder creates/updates route objects and ROAs that would result in inconsistencies? What do you think about an UI feature that says something like: "You are about to change/create the route object for prefix ... would you also like to update the existing ROA to match the route object and help avoid inconsistencies?" [ ] yes [ ] no, I know what I'm doing, I'll fix the mismatch manually similarly for updating/creating ROAs. Should there even be a 'No' option? Should the question even be exposed to the user or should records simply be synced automatically once one of either is changed by the IP holder? and simply showing an info like: "We took care of updating your ROA/route object to keep in sync." In case there are well established best practices for an ASN change of a prefix these best practices should be incorporated (i.e. delete the route object and ROA, change the actual announcement in BGP, create new route and ROAs that match the announcement) kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 3

Whois release 1.92.5 deployed to Production
by Edward Shryane 11 Sep '18

11 Sep '18

Dear Working Group, after deploying the NWI-5 changes last week, we found an issue preventing out of region transfers (the top-level placeholder template still referenced the RPSL maintainer). We have now deployed a bug-fix release 1.92.5 to production that fixes this issue. Regards Ed Shryane RIPE NCC

1 0

Re: [db-wg] WG Chair Selection - Call for Discussion
by Erik Bais 10 Sep '18

10 Sep '18

In case of 1 chair this time, my vote would be for Sean Stuart. Piotr already got selected for the RIPE exec board last meeting, I’m sure he has enough to deal with on that ‘WG’ 😉 Sean has been looking for a way to volunteer for a while in the community and his background could provide a good fit for the role imho. 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: Wednesday 5 September 2018 at 22:32 To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Subject: Re: [db-wg] WG Chair Selection - Call for Discussion WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

2 1

Re: [db-wg] WG Chair Selection - Call for Discussion
by Andy Davidson 06 Sep '18

06 Sep '18

Hi, William Thank you kindly for working on this process. Please could you confirm how many seats are open for selection this time? Are we selecting for one seat or two from this list of people? Andy

2 1

Status Update on NWI-5 Deployment: Completed
by Nathalie Trenaman 05 Sep '18

05 Sep '18

Dear colleagues, On 4 September, 21:55 UTC+2, we completed the following changes needed for NWI-5: Out of region ROUTE(6)/AUT-NUM objects. - Removal of mnt-routes from AUT-NUM objects - Removal of the RIPE-NCC-RPSL-MNT - Update the source attribute for out-of-region ROUTE(6) objects to RIPE-NONAUTH On 5 September, 04:32 UTC+2, we also completed the new database dump and split files at: ftp://ftp.ripe.net/ripe/dbase/ <ftp://ftp.ripe.net/ripe/dbase/> We have updated the release notes accordingly: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… <https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel…> Of course, we will keep monitoring the impact on operators. We would like to thank everyone who contributed with valuable input during the test and deployment phases. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

2 1

Implementation plan and time line for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.
by Nathalie Trenaman 05 Sep '18

05 Sep '18

Dear colleagues, On Tuesday, 4 September, we will make changes to the way out-of-region objects are handled in the RIPE Database, as directed by the RIPE Database Working Group. We will implement the following changes in this order between 09:00 and 15:00 UTC+2. 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder 3. Existing out-of-region objects will have their "source:" attribute changed to "RIPE-NONAUTH” For users of NRTM, these changes will be reflected on the FTP website after 00:00 UTC+2 on Wednesday, 5 September. You can find our implementation plan at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> We also published an article on RIPE Labs with some background and additional context: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec…> We will inform the Database Working Group once all changes have been implemented. Kind regards Nathalie Trenaman Product Manager RIPE NCC

2 2

Status Update on NWI-5 Deployment
by Nathalie Trenaman 04 Sep '18

04 Sep '18

Dear colleagues, We are currently deploying the changes for NWI-5 in the RIPE Database. At the moment, we have successfully rolled out: - the removal of mnt-routes from AUT-NUM objects - removal of the RIPE-NCC-RPSL-MNT The rollout of updating the “source:" attribute to RIPE-NONAUTH on out-of-region ROUTE, ROUTE6 and AUT-NUM objects is taking slightly longer than expected. This means that the source will gradually be updated on out-of-region objects for the rest of today as the script runs. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

1 0