Minutes for DB-WG at RIPE 69, November 2014 A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda No additional agenda items . approval of minutes from previous WG meeting(s) Minutes. Circulated only very recently so will hold for 3 weeks until approving. . review of action list AP67.4 [WW144] Take the issue of geolocation to the RIPE NCC Services Working Group as it does not seem to be heavily used. (Ongoing) AP67.5 [WW144] To check that the Anti-Abuse Working Group has properly specified both what should be done with mail that is sent to the abuse contact and (possibly) its format. (Ongoing) AP67.6 [WW144] To bring to the attention of the Routing WG the fact that the routing data as recorded in the DB is generally very poor (Report by Alexander Azimov) (Ongoing) AP68.1 [RIPE NCC] Remove the referral-by attribute (In progress) B. Working Group Management (Nigel T.) [~10 min] . chair replacement procedure See presentation Procedure accepted . WW144 to resign Thanks to Wilfried for all his years service. . new DB-WG Co-Chairs to take over at the end of session Job and Piotr C. Data Base Operational Update (Tim B., RIPE NCC) [~10 min] See presentation. All open issues are tracked on Github Release Candidate environment is available for at least two weeks prior to release so that full testing may take place. Documentation is on line and is tied to each release. RIPE Academy is providing DB training Abuse-c cleanup is well advanced Question: will one of the abuse contact finders be abandoned once this exercise is complete? Answer: no for the RIPE NCC region we will only check the abuse-c but the two tools can be merged. Question: When will API keys be authenticated by the system Answer: It is on the agenda but we are waiting for guidance from the WG D. New DB-Software functionality (Tim B. RIPE NCC) [~35 min] (proposed, test, deployment) See presentation . referral-by deprecation - (based on deprecation guidelines) - present time table for 'referral-by' Removal in three phases over 4 months . from "changed:" to "last-modified:" / "created:" - explain new attr., examples, - timeline for implementation Three phases over 5 months. Comments (RV) was that such changes should be written down formally in advance. Response was that this has been extensively discussed on the mailing list and the details have been available for months. RIPE NCC noted that it would be relatively easy to produce such a document. [AP69.1][RIPE NCC] Come forward with a self contained document describing the migration of the changed: attribute to the last-modified:/created: attributes proposal Another question was asked about objects in the database which have no changed: lines, what date was it created? The response was that the relevant data will be pulled from the database and added to the object. RV asked that there was some syntactic markup to separate system added attributes from user added attributes. It was pointed out that the -t flag already tells you this. RV responded that this wasn't enough. It was asked whether all the attributes of auto-generated objects should be marked as such. It was agreed to discuss this on the mailing list. It was suggested that whatever history is available might be incorporated, including data from ERX and other registries. It was agreed to discuss in the mailing list [AP69.2][RIPE NCC] Come up with some straw man proposals for doing this E. Personalised authentication? (Tim B. RIPE NCC, all) [~5 min] See presentation More detailed proposal following requests on the list and at the last meeting WG feedback is needed about how to do this. The proposal is to add person authorisation using a Single Sign On authentication. Maintainers are also difficult and non-intuitive Suggestion is to use roles everywhere. The advantage is that this is consistent and it is easy to see who is who An alternative is to have optional persons in maintainer objects There will be an issue with migrating existing maintainer objects. Any migration mechanism should ideally be capable of automation. Existing tools can be relatively easily modified to check all possible authentication methods. Suggestions were presented on how the migration to using roles could be semi-automatically handled. All comments gratefully received. Adding optional persons to maintainers could be easier to migrate. Discussion needs to take place on the WG Some comments on the perceived complexity of the maintainer object took place and it was suggested that some good concise documents on the maintainer object might help. It was agreed that it would not be a good thing to take away the maintainer object. F. Maintainer Password resets? (Tim B. RIPE NCC, all) [~5 min] See presentation 25% of all ripe-dbm requests are password resets Rather than removing all authentication RIPE NCC is now adding SSO auto and allowing the member to get access that way instead. G. "reviving" the WG, active participation (Job S.) [~10 min] See presentation Participation in the group has dropped off in the last 12 months. Why has this happened? Response from RV was that the database is in reasonable shape and is heavily used in production. The fact that it doesn't need a lot of modification is actually a strength. It was noted that database accuracy is very important and maybe the WG should be thinking about how to improve accuracy of the data. It was noted that some of the changes proposed were taking place far too quickly for large organisations to follow. It was pointed out by the RIPE NCC training group that many users only use the database 2 - 3 times a year and find it difficult to keep current. Rapid changes would make this even more difficult. A call was made for IPAM developers to use the RIPE DB API and Softlayer responded that they used it extensively. The RIPE NCC said that they were very happy to work with anyone using the DB to improve it and improve the interface into it. Y. Input from other Working Groups and/or Task Forces RV pointed out that the Abuse WG really needs to provide proper documentation on the Abuse-C attribute and he suggested that it should be made optional until such documentation is produced. It was agreed that this should be chased with the Anti-Abuse. It was pointed out that Anti-abuse TF decided that the abuse-c should come first and the population of it should come second. A representative from the Routing WG noted that it is easy for "foreign" prefixes to be entered into the database and these can be used for various nefarious purposes. It was suggested that such foreign prefixes should be validated using RPKI. It was asked that the routing WG should come back to the DB mailing list with this request. Z. AOB Geolocation. Tim Robinson from TXRX communication, saying that he has problems with getting his IP blocks recognised as being from the UK. JS agreed with the problem statement. There isn't a global source of accurate geolocation data. Should we make it easier to consume the geolocation data already in the DB? This appears to be an issue with the data providers who can't be bothered to provide the data in the database. It was pointed out that browsers generally have a very good idea of location and language and this is a more appropriate source of location data than the database. [AP69.3][RIPE NCC] To examine and report on possible solutions to improving geolocation data in the RIPE DB