RIPE 64

Thursday, 19 April, 14:00 – 15:30

A. Administrative Matters

• Welcome
• select scribe (Nigel Titley)
• finalise agenda
  No additional items
• approval of minutes from previous WG meeting(s)
  Minutes had been submitted to the mailing list, no comments received
  Accepted as final
• review of action list (NT13)
  
  [AP57.2] [RIPE NCC] Cleanup of forward domain data. Now complete and closed.
  [AP63.1] [WW144] Gelocation proxy. Ongoing
  [AP63.2] [RIPE NCC] UTF-8 compliance. Technically it works but it hasn't been properly tested. Not recommended. Discharged.
  [AP63.3] [Dave Freedman] Raise issue of reverse lookup method for aut-num objects on the mailing list to find out if this was a desired feature. Ongoing.

B. RIPE Database Update

- Alex Band and Denis Wlison, RIPE NCC

See presentation

general update
Half a billion database queries per month.
There was an extended IPv6 downtime, but this was caused by connectivity and not system problems. It remained accessible over IPv4.
MD5 hashes have now been hidden and all MD5 hash users have been emailed suggesting they update their passwords. Over 8000 bounced mails came back. This suggests some decay in data accuracy. Not a lot of effect (roughly 700 passwords changed). Plaintext passwords in emails are still an issue, but some steer is needed from the community.

geolocation status/implementation
Now available as an optional (single) attribute in beta as is the language (multiple) attribute.
Need furthur discussion and testing.

internationalisation
No policy currently defining when UTF-8 should be used in the database.
Need to wait for this policy before it can be tested. This needs to be taken up on the mailing list.

projects

• Whois

Brand new whois application. Current version is 11 years old. The new service is running in parallel with the old one. New version is much more efficient and flexible. 94% of queries are handled by the new software. Code will be provided to the other RiRs and will be OpenSource. Written in java. The old service will be decommisioned shortly.

• Update

This will be implemented soon and should hopefully lead to a simpler interaction with the database to enable new users to get up to speed more quickly. This should lead to better data quality. The community does need to help with this.

• UI

Integrated with RIPEstat
Simpler password generation.
More to follow

• API

RESTful queries are being standardised by IETF
Prototype RESTful redirects to other RIRs are being worked on.

A question was received about asused. Alex stated that it would be very difficult to re-create a command line facility with exactly the same functionality and that it is low (or zero) priority at present.

C. RIPEstat

- Robert K., RIPE NCC

See presentation

new way of accessing database content
Note the link between the RIPE DB to RIPEstat referred to above.

New widgets
Object browser allows you visualise the relationship between objects in the database. It is now easy to click through objects and get the information about the relationships between them. Personal data is not displayed. History is not
shown at present but it is possible to display this. Access limits will be applied (see presentation). The RIPE NCC would appreciate some feedback on how useful this visualisation would be. Training course feedback is generally favourable. Single sign-on seems to be a good intermediate access level control.

Comments were that this is fixed display size. The response was that this is a widget and can change size as you wish. Other RIPEstat items are being converted to widgets as well. A note was made that this could be a useful service and might be used to distinguish between different classes of user (beware: dragons).

D. Review of implementation of auth: filtering

filtering of public key information
No only the MD5 hashes but also the public key information. This was not what was needed. It has broken email updates for some members. The response was that this simplies things for newcomers. The third possibility is to only show PGP attributes but remove the MD5 value. There seemed to be some support for this in the room.
The point was again made that this has broken a lot of automated tools, although noting that such users should really be looked at the mailing list and should be contributing to the development.
It was agreed that some compromise should reached.

Y. Input from other WGs and/or TFs

APWG: is there a referral mechanism for inet[6]num in the DB code?
Should there be a means of referring objects from one RIR or another to allow for inter RIR transfers?
This should not be done at the http-redirect level.
The IETF is working on this with a proposal to sit on top of the RESTful API and provide the redirect. Care has to be taken not to get into loops.
So the response is that technically it can be done but requires careful consideration so as not to cause operational problems.

Z. AOB