Wednesday, 15 May, 9:00 – 10:30
A. Administrative Matters
- Select scribe (Nigel Titley)
- Finalise agenda; item D will be a presentation from Piotr on internationalisation of the database rather than update on WEIRDS
- Approval of minutes from previous WG meeting(s); Approved
- Review of action list; all items dealt with in the presentations below
B. Data Base Operational Update
Kaveh Ranjbar, RIPE NCC
No downtime on the database in the last six months. Availability is now being measured through RIPE Atlas.
The software has been completely replaced, with no down time.
New software is fault tolerant, easy to deploy and easy to scale.
The new software is fully standardised (standard mysql replication). No more home grown protocols.
Code is now open source (BSD license), easy to install and change.
- [AP65.1] Org object updated: no need to update the object at all with the new code. All objects already have an ORG reference. Action point discharged.
- [AP65.2] Geolocation: still ongoing (Alex Band working on this)
- [AP65.3] Personal data in history: no personal data objects are returned in the history (NIC handles are retrieved). Problem is that NIC handles have been reused over the years. Service has been cleared by legal. No history of deleted objects is returned. Question was raised about data retention? Are we sure that we are not falling foul of data retention legislation? Answer is that because we are not returning personal data, we are probably OK (this is a grey area).
- [AP65.4] Abuse-c implementation: implementation and impact analysis were published beforehand. Action point discharged.
C. New RIPE Database Software Functionality
The API code has been redeveloped: now much faster, consistent and self documenting. Backward compatible but now handled directly from the whois core.
History of objects. Available through API and WEB as well as port 43. Already seeing some use.
Improvements on Dummification: all personal data is currently removed from nightly dumps. Proposal is to make the algorithm less greedy and retain parts of phone numbers, email addresses and addresses. This will make the dataset much more useful to researchers. Sent to list and still being discussed. Concern was expressed that partial dummification may create data linkages that do not exist, also that the remaining data might be useful to those of wicked intent. There was also some concern that researchers are not the primary consumers of the RIPE database. There was a feeling that the design goals should be further clarified before going forward.
[AP66.1] [RIPE NCC] Return to the community for clarification of design goals.
Tags: make metadata available along with updates. Results can be filtered based on tags. Can be useful for data cleanup. No change to existing behaviour but an additional option to show tags or to filter based on tags.
Unref Object Automatic cleanup: Objects with no reference will be cleaned up after 90 days.
Placeholder cleanup: objects with no real benefit (eg 0/0 and AS-BLOCKS) can be removed. With proper tags they can all be removed. These are mostly imported from other RIR public data.
RIPE Easy whois: simple to use web interface for searching on resources. Clear indication of responsible entities for each piece of data.
Route object cleanup: proposal to change auth requirements for route object from IP address holder and ASN holder to only IP address holder. Concern was expressed that this effectively gives permission for the address holder to write to the AS owners routers. It was felt that this was a dangerous precedent.
[AP66.2] [RIPE NCC] Raise this proposal on the DB-WG mailing list for discussion.
Single sign-on proposal: new auth type in maintainer - auth: SSO sso_registered_email. This would be fully compatible with the existing system. Support was expressed from the floor for this.
[AP66.3] [RIPE NCC] Raise this proposal on the DB-WG mailing list for discussion.
Clean up documentation: badly needed and underway
D. Status Update on IETF WEIRDS Activities
No update available.
Piotr Strzyzewski: Presentation about internationalisation of resource registry
Presented at RIPE 61
Not implemented yet
Should this go to the PDP or not?
The main question that the RIPE NCC has is whether data should always have an english translation as well as (for example arabic).
Feeling was that this doesn't need a PDP but does require a consensus from the DB-WG as to whether multiple datasets are required (or allowed).
[AP66.4] [Piotr, NT13, WW144] Raise the issue with the RIPE NCC Services working group chairs and also on the DB-wg mailing list
[AP66.5] [RIPE NCC] Check that all systems are UTF8 ready
Y. Input from Other Working Groups and/or Task Forces
Review of Abuse contact stuff - Brian Nisbet.
There has been good takeup of abuse-c, more in the Anti-Abuse WG.
What next? We now want to push it further (probably in RIPE NCC Services). The right way is felt to be a proposal for verification of abuse-c data. This can then be applied to admin-c and tech-c. There will then be regular automated verification of contact details for all contact data.
No other items.