January 2018 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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

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 16 Feb '18

16 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 15 Feb '18

15 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

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 30 Jan '18

30 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 30 Jan '18

30 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