- db-wg - mailman.ripe.net

NWI-7: abuse-c implementation plan
by William Sylvester 03 Aug '17

03 Aug '17

Working group members, Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. Kind Regards, DB-WG Chairs

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Sebastian Wiesinger 27 Jul '17

27 Jul '17

* Gert Doering via db-wg <db-wg(a)ripe.net> [2017-07-20 09:42]: > > > its a broken process. it inherently permits things to be said, which > > > should not have been said. > > > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? > > This might indeed be the way forward for "I have a customer in my RIPE > AS which has APNIC space and wants to document that in a way that that > provisioning tools can pick this with sufficient trust on data quality". Yes please! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Call for Agenda Items DB-WG Meeting - RIPE75 - Dubai, UAE
by William Sylvester 25 Jul '17

25 Jul '17

Dear DB-WG Members, This is the call for agenda items for the DB-WG Meeting at RIPE75 at the Conrad Dubai in Dubai, UAE. Please submit agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net> The DB-WG Meeting is scheduled for Wednesday, October 25th, starting at 14:00 local time, after lunch and before the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 74 meeting plan please refer to its most up-to-date version at https://ripe75.ripe.net/programme/meeting-plan/ Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements We are looking forward to another successful meeting in Dubai. Kind regards, William, Denis, & David DB WG Chairs

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Gert Doering 20 Jul '17

20 Jul '17

Hi, On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: > > its a broken process. it inherently permits things to be said, which > > should not have been said. > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? This might indeed be the way forward for "I have a customer in my RIPE AS which has APNIC space and wants to document that in a way that that provisioning tools can pick this with sufficient trust on data quality". (And no, RADB is not) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Nick Hilliard 18 Jul '17

18 Jul '17

denis walker via db-wg wrote: > Just for the record I have followed all previous discussions on this > issue over many years within the RIPE community. There have been many > (opposing) views expressed. I don't recall any consensus within the RIPE > community to expel all, or even just Afrinic, (foreign) ROUTE objects > from the RIPE Database. If I did miss that, maybe someone can point me > to the message on this or the ROUTING WG mailing lists where that > consensus was drawn. NWI3 was proposed last year. Several people supported the idea and no-one was against it, at least at the time it was suggested. Previously two people thought this was a bad idea (one of these people was you) and stated so on the mailing list. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html No formal declaration of consensus was drawn by the wg chairs, but in the circumstances it looked like there was overall support for the idea. As a result of what appeared to be a community mandate, the RIPE NCC started a project which was reported on at the Copenhagen and Madrid meetings: https://ripe72.ripe.net/archives/video/217/ https://ripe73.ripe.net/archives/video/1510/ As Piotr noted in Madrid, there is not yet consensus on how this project should move forward. Right now, I believe that this may be the sticking point. > Does Afrinic have a mandate, with a clear consensus, from the Afrinic > community for the migration of all Afrinic ROUTE objects from the RIPE > Database to the Afrinic Database? Has either community agreed anything > on the (re)creation of Afrinic ROUTE objects in the RIPE Database? The Afrinic people would be best placed to provide feedback on how this proposal has been received by the Afrinic community. Maybe Daniel could comment? Nick

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Tim Bruijnzeels 18 Jul '17

18 Jul '17

> On 18 Jul 2017, at 17:03, Sander Steffann via db-wg <db-wg(a)ripe.net> wrote: > > > From: Sander Steffann <sander(a)steffann.nl> > Subject: Re: [db-wg] out of region routing in the RIPE Database > Date: 18 July 2017 at 16:10:09 GMT+2 > To: George Michaelson <ggm(a)algebras.org> > Cc: Nick Hilliard <nick(a)foobar.org>, Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > > > Hi George, > >> I think the previously stated position from APNIC region is clear: we >> have problems with the logistics which permit resources from our >> region to be included in IRR statements in the RIPE DB, when no formal >> check is made of permission or integrity, and we do not see any clear >> path to a deployable mechanism to provide authorization checks over >> resources from out of region. >> >> its a broken process. it inherently permits things to be said, which >> should not have been said. > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? Thanks sander, we will certainly look into the options and report back to the wg group. Tim

2 1

out of region routing in the RIPE Database
by denis walker 18 Jul '17

18 Jul '17

Hi Daniel and others Just for the record I have followed all previous discussions on this issue over many years within the RIPE community. There have been many (opposing) views expressed. I don't recall any consensus within the RIPE community to expel all, or even just Afrinic, (foreign) ROUTE objects from the RIPE Database. If I did miss that, maybe someone can point me to the message on this or the ROUTING WG mailing lists where that consensus was drawn. Does Afrinic have a mandate, with a clear consensus, from the Afrinic community for the migration of all Afrinic ROUTE objects from the RIPE Database to the Afrinic Database? Has either community agreed anything on the (re)creation of Afrinic ROUTE objects in the RIPE Database? I have no personal interest in this either way. I just want to be clear what the current position is so we can move forward. cheersdenisco-chair DB-WG From: Daniel Shaw via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Tuesday, 18 July 2017, 16:39 Subject: Re: [db-wg] out of region routing in the RIPE Database On 18/07/2017, 15:26, Nick Hilliard via db-wg typed: > > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. Hello WG, That matches my recollection too. And so I'll re-iterate that, as previously mentioned on this list, this neatly matches up with some parallel goals within AFRINIC. Which is that regardless, we see an advantage in having our membership manage their IRR along with RDNS and RPKI and other registry interactions in one place under one authentication. Simpler. And we also see an advantage in general growth in usage of the AFRINIC IRR by our membership, as it's a service we already provide and will maintain and scale as needed in any case. And so, we do already provide tooling to our membership to assist them moving objects into the AFRINIC DB easily. We do liaise with upstream operators of our members when they have in the past implied a requirement for RIPE DB IRR objects. And our hostmasters also do run bootcamp tutorials at nog and other events to encourage migration of objects. In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC route(6) objects underway. I will add that this is a long and slow process however. The work is done as convenient. And for now, only applies where both the IPv{4,6} an AS resources are within the AFRINIC region. The movement is slow. But in the direction of moving AFRINIC resources away from RIPE DB. Regards, Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 18 Jul '17

18 Jul '17

On 18/07/2017, 15:26, Nick Hilliard via db-wg typed: > > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. Hello WG, That matches my recollection too. And so I'll re-iterate that, as previously mentioned on this list, this neatly matches up with some parallel goals within AFRINIC. Which is that regardless, we see an advantage in having our membership manage their IRR along with RDNS and RPKI and other registry interactions in one place under one authentication. Simpler. And we also see an advantage in general growth in usage of the AFRINIC IRR by our membership, as it's a service we already provide and will maintain and scale as needed in any case. And so, we do already provide tooling to our membership to assist them moving objects into the AFRINIC DB easily. We do liaise with upstream operators of our members when they have in the past implied a requirement for RIPE DB IRR objects. And our hostmasters also do run bootcamp tutorials at nog and other events to encourage migration of objects. In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC route(6) objects underway. I will add that this is a long and slow process however. The work is done as convenient. And for now, only applies where both the IPv{4,6} an AS resources are within the AFRINIC region. The movement is slow. But in the direction of moving AFRINIC resources away from RIPE DB. Regards, Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by George Michaelson 18 Jul '17

18 Jul '17

On Tue, Jul 18, 2017 at 4:10 PM, Sander Steffann via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Sander Steffann <sander(a)steffann.nl> > To: George Michaelson <ggm(a)algebras.org> > Cc: Nick Hilliard <nick(a)foobar.org>, Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > Bcc: > Date: Tue, 18 Jul 2017 16:10:09 +0200 > Subject: Re: [db-wg] out of region routing in the RIPE Database > Hi George, > >> I think the previously stated position from APNIC region is clear: we >> have problems with the logistics which permit resources from our >> region to be included in IRR statements in the RIPE DB, when no formal >> check is made of permission or integrity, and we do not see any clear >> path to a deployable mechanism to provide authorization checks over >> resources from out of region. >> >> its a broken process. it inherently permits things to be said, which >> should not have been said. > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? Not a bad idea, I wouldn't oppose. Why do we have the NRO, if not to coordinate these kind of things? -George

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Sander Steffann 18 Jul '17

18 Jul '17

Hi George, > I think the previously stated position from APNIC region is clear: we > have problems with the logistics which permit resources from our > region to be included in IRR statements in the RIPE DB, when no formal > check is made of permission or integrity, and we do not see any clear > path to a deployable mechanism to provide authorization checks over > resources from out of region. > > its a broken process. it inherently permits things to be said, which > should not have been said. Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? Cheers, Sander

1 0

Re: [db-wg] out of region routing in the RIPE Database
by George Michaelson 18 Jul '17

18 Jul '17

as a passive (mostly) participant, this is mostly my recollection too. as a non passive participant... I think the previously stated position from APNIC region is clear: we have problems with the logistics which permit resources from our region to be included in IRR statements in the RIPE DB, when no formal check is made of permission or integrity, and we do not see any clear path to a deployable mechanism to provide authorization checks over resources from out of region. its a broken process. it inherently permits things to be said, which should not have been said. if some strong checks can be created, and if a remote DB referential integrity issue can be resolved, I think we could discuss this. If the intention is to continue using open maintainer to add any non-RIPE resource? thats a really bad model. -George On Tue, Jul 18, 2017 at 3:25 PM, Nick Hilliard via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Nick Hilliard <nick(a)foobar.org> > To: denis walker <ripedenis(a)yahoo.co.uk> > Cc: Database WG <db-wg(a)ripe.net> > Bcc: > Date: Tue, 18 Jul 2017 14:25:05 +0100 > Subject: Re: [db-wg] out of region routing in the RIPE Database > denis walker via db-wg wrote: >> We would like to start off the (final?) round of discussions on this >> topic with a question. Should the RIPE Database be used as an open, >> free, global Internet Routing Registry (IRR)? If the answer is 'yes' >> then perhaps we should allow the routing policy of any global resource >> to be documented in the RIPE Database as a choice by the resource holder >> and move on to address the issues surrounding this process. If the >> answer is 'no' then perhaps we shouldn't allow any routing policy for >> any non RIPE resources (not selectively try to expel one group of ROUTE >> objects). > > I am not in favour of having the RIPE database as an open-access > database on the basis that this mixes up two sets of data, authoritative > and non-authoritative, and it it is impossible for someone casually > querying the database to determine which is which. > > Some people are inserting random route: objects into the database, and > those route: objects are being picked up by provisioning systems and > ending up configured on routers and IXP route servers. This enables > prefix hijacking, which is a pressing operational issue. > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. I believe the plan was to > continue on after that with other categories of objects. This > recollection may be wrong. > > Nick > >

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Nick Hilliard 18 Jul '17

18 Jul '17

denis walker via db-wg wrote: > We would like to start off the (final?) round of discussions on this > topic with a question. Should the RIPE Database be used as an open, > free, global Internet Routing Registry (IRR)? If the answer is 'yes' > then perhaps we should allow the routing policy of any global resource > to be documented in the RIPE Database as a choice by the resource holder > and move on to address the issues surrounding this process. If the > answer is 'no' then perhaps we shouldn't allow any routing policy for > any non RIPE resources (not selectively try to expel one group of ROUTE > objects). I am not in favour of having the RIPE database as an open-access database on the basis that this mixes up two sets of data, authoritative and non-authoritative, and it it is impossible for someone casually querying the database to determine which is which. Some people are inserting random route: objects into the database, and those route: objects are being picked up by provisioning systems and ending up configured on routers and IXP route servers. This enables prefix hijacking, which is a pressing operational issue. There are two main ways to fix this problem: 1. change all non-RIPE address space to have a different source: tag 2. remove all non-RIPE address space completely There is some previous discussion about this issue on db-wg, and IIRC, the WG suggestion was to go for option #2. On that basis, again IIRC, there was a suggestion to handle this in a phased way, starting off with the lowest hanging fruit first. As Afrinic objects formed the largest share of all out-of-region objects in the ripedb, they were targeted first. I believe the plan was to continue on after that with other categories of objects. This recollection may be wrong. Nick

1 0

out of region routing in the RIPE Database
by denis walker 18 Jul '17

18 Jul '17

Colleagues The DB-WG co-chairs would like to try to resolve (or close and document that as a consensus) another long standing issue, out of region ROUTE(6) and AUT-NUM objects in the RIPE Database (NWI-5). We would like to start off the (final?) round of discussions on this topic with a question. Should the RIPE Database be used as an open, free, global Internet Routing Registry (IRR)? If the answer is 'yes' then perhaps we should allow the routing policy of any global resource to be documented in the RIPE Database as a choice by the resource holder and move on to address the issues surrounding this process. If the answer is 'no' then perhaps we shouldn't allow any routing policy for any non RIPE resources (not selectively try to expel one group of ROUTE objects). cheers denis co-chair DB-WG

1 0

Re: [db-wg] org field in the organisation object
by denis walker 13 Jul '17

13 Jul '17

Hi Sergey The original design of the ORGANISATION object was to allow for them to be used hierarchically. So there could be a chain of trust between organisations. But nothing was ever implemented in that way. cheersdenisco-chair DB-WG From: Sergey Myasoedov via db-wg <db-wg(a)ripe.net> To: DB-WG <db-wg(a)ripe.net> Sent: Thursday, 13 July 2017, 17:18 Subject: [db-wg] org field in the organisation object Dear Working Group, What is the goal of the org field in the organisation object? Thank you. -- Kind regards, Sergey Myasoedov

1 0

org field in the organisation object
by Sergey Myasoedov 13 Jul '17

13 Jul '17

Dear Working Group, What is the goal of the org field in the organisation object? Thank you. -- Kind regards, Sergey Myasoedov

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Andreas Worbs 11 Jul '17

11 Jul '17

Yes, go ahead :) Am 11.07.17 um 09:02 schrieb denis walker via db-wg: -- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Gert Doering 11 Jul '17

11 Jul '17

Hi, On Wed, Jun 28, 2017 at 01:56:49PM +0200, Tim Bruijnzeels via db-wg wrote: > Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to ???abuse-c:??? that the working group seeks. I think the proposed implementation makes sense, reducing overhead for maintaining the abuse contacts, while at the same time still giving a very clear order of precedence when querying -> works for me! Gert Doering -- long time LIR DB user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Piotr Strzyzewski 11 Jul '17

11 Jul '17

On Mon, Jul 10, 2017 at 07:37:37PM +0200, denis walker via db-wg wrote: Dear All > It is almost two weeks since Tim sent out a proposed implementation > plan and timeline. Can we assume no comments mean acceptance? If > anyone has any specific comments can we here them please. I see no reasons to wait for implementing the plan. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Sebastian Wiesinger 11 Jul '17

11 Jul '17

> Colleagues > It is almost two weeks since Tim sent out a proposed implementation > plan and timeline. Can we assume no comments mean acceptance? If > anyone has any specific comments can we here them please. Hello, after two weeks of vacation I'm back and I support this implementation. Happy to see this topic come to conclusion this time! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by denis walker 10 Jul '17

10 Jul '17

Colleagues It is almost two weeks since Tim sent out a proposed implementation plan and timeline. Can we assume no comments mean acceptance? If anyone has any specific comments can we here them please. Regardsdenisco-chair DB-WG From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> To: William Sylvester <william.sylvester(a)addrex.net> Cc: DB-WG <db-wg(a)ripe.net> Sent: Wednesday, 28 June 2017, 13:57 Subject: Re: [db-wg] NWI-7: abuse-c implementation request Dear working group, Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to “abuse-c:” that the working group seeks. We expect that this will have a MEDIUM impact on the RIPE NCC. The RIPE Database Group Software team will have to implement changes, but because a clean-up of “abuse-mailbox:” is also in-scope of this proposal we also expect impact on our Customer Service department due to questions from users of the RIPE Database. We propose an implementation using the following phases: 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: abuse-c: [optional] [single] [inverse key] The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: -the local "abuse-c:" in the resource object -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object -search up the resource object hierarchy (less specific objects) --the "abuse-c:" in the less specific resource object --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object The search will stop when the top level resource object is reached. In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. 2) Clean up of “abuse-mailbox:” on ORGANISATION objects Three cases exist: A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) In these cases we propose to send a warning email to the holders of these objects with the following main message: “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." And then 4 weeks later we will preform the clean-up and refer back to this communication. 4) Clean up whois code Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. 5) Inverse queries As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: whois -r -i pn uk41-ripe Instead of: whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. 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 statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

New on RIPE Labs: Unifying the LIR Portal and RIPE Database User Experience
by Mirjam Kuehne 10 Jul '17

10 Jul '17

Dear colleagues, Over the years, the core services of the RIPE NCC, such as the LIR Portal and RIPE Database, have seen many changes. We are now going to unify the interfaces. Please find more details on RIPE Labs: https://labs.ripe.net/Members/AlexBand/unifying-the-lir-portal-and-ripe-dat… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Tim Bruijnzeels 28 Jun '17

28 Jun '17

Dear working group, Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to “abuse-c:” that the working group seeks. We expect that this will have a MEDIUM impact on the RIPE NCC. The RIPE Database Group Software team will have to implement changes, but because a clean-up of “abuse-mailbox:” is also in-scope of this proposal we also expect impact on our Customer Service department due to questions from users of the RIPE Database. We propose an implementation using the following phases: 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: abuse-c: [optional] [single] [inverse key] The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: -the local "abuse-c:" in the resource object -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object -search up the resource object hierarchy (less specific objects) --the "abuse-c:" in the less specific resource object --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object The search will stop when the top level resource object is reached. In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. 2) Clean up of “abuse-mailbox:” on ORGANISATION objects Three cases exist: A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) In these cases we propose to send a warning email to the holders of these objects with the following main message: “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." And then 4 weeks later we will preform the clean-up and refer back to this communication. 4) Clean up whois code Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. 5) Inverse queries As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: whois -r -i pn uk41-ripe Instead of: whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. 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 statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by Tim Bruijnzeels 21 Jun '17

21 Jun '17

Dear Working Group, The average update rate to the RIPE Database is 12 updates per minute. As shown the system is capable of handling a sustained rate of over 700 updates per minute for inetnums through mail updates without issues. That is 60 times the average rate. Cases where people actually need to do updates exceeding this rate are very few and far in between. This does not warrant allocating resources to improve this further - our efforts are better spent in other areas such as improving the usability of the user interface to help people manage their content better. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by Horváth Ágoston János 20 Jun '17

20 Jun '17

Hi Jeroen, I'm probably the most relevant person to asnwer your question right now, having been a core developer during the ripe database reimplementation project in 2013. We did that by running side by side with the old, C version of the ripe database software. As such, we were in no position to change the underlying database or its format. And guess what, the underlying database is coming from the previous server's reimplementation project, all the way from 2000. Reminds me of the story of the NASA booster rocket and the roman horse. There have been minor updates done over the years (like switching to innodb and sql transactions), the basics are still the same. Its data model is 100% optimized for query performance (since queries outnumber updates 100 to 1 or more). And most importantly, since updates (can and often do) have effect on one another, they are strictly serialized (as in, single-threaded). On top of that, all updates go through a rigorous rule checks before being accepted and taking effect. All this translates to that update performance. Note that the update performance is much higher for simple object types (say, person; my last knowledge was over 2000 objects/min), and very slow for complex ones (namely aut-num, with all the extra DNS checks). In practice, it was never an issue that a longer update ran for hours. This performance could be improved greatly given enough priority though. It was always a simple case of this requiring quite some dirty hack or major refactors, while this issue was always considered a minor nuisance, not enough to warrant either. BTW, if you look at the update graph you included, you see that updates are normally almost negligible compared to your batch. Thus most users of ripe database updates see very quick response times. I'd maintain that unless this really stops you from achieving your goals, it's probably best to leave the engineers work on deeper / more pressing issues. Like the fact that the RIPE DB actually needs a massive documentation and a day long training course even for basic usage. And even then, people are struggling with the weird object hierarchy and rules. While could be considered an acceptable approach in '99, this is way outdated by today's standards and user expectations. Cheers, Agoston On Tue, Jun 20, 2017 at 2:23 PM, Jeroen Massar via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Jeroen Massar <jeroen(a)massar.ch> > To: db-wg(a)ripe.net > Cc: > Bcc: > Date: Tue, 20 Jun 2017 14:22:49 +0200 > Subject: 2017 and RIPEdb only handles 700 updates per *MINUTE* > https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates > > (see attached png for the current version as over time it will disappear) > > shows a nice peak with a max of 723.47 updates. > > Thus either the software is really bad, the updates are rate limited, or > the queries are so high that no further performance is to be expected. > > > As alluded to in the other thread, if there was less junk (those 400k > inet6nums for instance) then likely this would all scale better.... > > Are the RIPE DB-WG chairs still actively involved in the maintenance of > the RIPE Database!? > > As two of the co-chairs are working for RIPE NCC, are they able to tell > why such a process is slow and why these problems that are being raised > over and over on the various lists are not being resolved? > > Greets, > Jeroen >

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by denis walker 20 Jun '17

20 Jun '17

HI Jeroen The three DB-WG co-chairs (2 of whom are former RIPE NCC staff) are still actively involved in overseeing the maintenance of the RIPE Database. We don't have any 'hands on' involvement. Things may have changed a little since I was working on the RIPE Database so I am sure Tim will correct me if I am wrong here. Updates sent by email are queued and processed sequentially. It is a batch process, not real time as with Syncupdates or Webupdates. If you submit a single email with a huge number of objects, each of those objects are processed one at a time sequentially. If you submit several emails in quick succession with that huge list of updates spread over them, the emails will be queued and processed sequentially. Not sure now if there is only one queue or several for email updates. AFAIK the database can only update a single object at a time, no matter how many processors are running to feed updates to the database. The bottom line is, if you submit a huge number of objects to be updated it will take some time to complete. The number of daily queries massively outweighs the number of updates. So performance is naturally optimised to serve the query load. The average number of updates is easily handled, but when you get spikes it does slow down the update process for a while. The number of objects in the database makes no difference to performance on either queries or updates. So a large amount of junk will not affect performance. To address a couple of your points from your previous email. No one has ever defined what the "country:" attribute in an INET(6)NUM object means. It could be the location of the registries head office, their data centre, their service desk, their user base... It is not uncommon to see this value 'apparently' conflict with netname or address. If you believe 40% of the INET6NUM objects in the RIPE Database are junk, that is something the RIPE NCC Registration Services needs to comment on. cheersdenisco-chair DB-WG From: Jeroen Massar via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Tuesday, 20 June 2017, 14:23 Subject: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE* https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates (see attached png for the current version as over time it will disappear) shows a nice peak with a max of 723.47 updates. Thus either the software is really bad, the updates are rate limited, or the queries are so high that no further performance is to be expected. As alluded to in the other thread, if there was less junk (those 400k inet6nums for instance) then likely this would all scale better.... Are the RIPE DB-WG chairs still actively involved in the maintenance of the RIPE Database!? As two of the co-chairs are working for RIPE NCC, are they able to tell why such a process is slow and why these problems that are being raised over and over on the various lists are not being resolved? Greets, Jeroen

1 0