RIPE 63

• Thursday, 3 November 2011
  
• content to the Chair of the working group.
• format to [email protected].

A. Administrative Matters

• Welcome
• select scribe (Nigel Titley)
• finalise agenda
  No changes
• approval of minutes from previous WG meeting
  Approved
• review of action list
  All Action items have been completed and will be reported on by the RIPE NCC Database group.

B. Data Base Update (Kaveh Ranjbar, RIPE NCC)

See presentation

- brief update

For queries, the uptime is very close to 100%
Action items:
57.2 Cleanup of domain data.
41 have been deleted, 2 left. By 1st Feb 2012 this will be done.
62.2 Review domain attributes
Proposed to drop unused attributes, nserver will be required for reverse.
62.3 TLS query service
Prototype has been deployed (June 2011)
62.4 Statistics on password
86% of MNTERs only have a password. In reality, passwords are the
main protection mechanism.
62.5 Dash notation in reverse DOMAIN objects
Implemented.
62.1 Geolocation prototype
Prototype is now available on Ripe labs. Discussion later on down the agenda.
Some discussion on the list. Play with it and send feedback to the list.

- The Road Ahead (core software reimplementation)

Database infrastructure is being rewritten with greater reliability.
Agile software development model means that turnaround is much quicker.
GRS is now in production, which means that the other RIRs are now mirrored on a daily basis, and all data is available in RPSL format (even for ARIN).
The REST API is now used exclusively within RIPE NCC to interface with the database.

The core database software is being re-implemented as it is now more than ten years old. Queries are being moved onto the new software first.

Database related processes are being streamlined to make the web interface easier to use. It will be much more obvious which is RIPE NCC maintained data and what comes from the user.

Geolocation has been requested by users and some work has been done on this. Prototype has been produced but needs a lot of work.

C. Internationalisation of the Registry System

- Problem statement and goals

Some of the problems which are being uncovered in the domain name system are equally applicable to the numbers system. Most of our tools are based on 7-bit ASCII. This is changing and we need to change to adapt.
There are at least 5 different language systems used in the RIPE NCC service region.

- Mandate to the NCC / implementation approach?

Do we need to ask the RIPE NCC to make sure that the whole system is 8-bit capable?

Strong support from at least one member. APNIC supports multiple languages and scripts. However this does need to be very carefully examined. Liaison with APNIC would certainly be called for.

At the moment, the database core is pure 8 bit. Probably 95% of the interface functionality is 8 bit compatible. The browser interface prefers UTF-8 which has a strong overlap with Latin 1.
A clear mandate from the community would be appreciated by the RIPE NCC.

The question was raised as to what was the policy? RIPE NCC can do almost anything.

It has already been proposed that there will be mandatory English fields and optional non-English fields.

An APNIC representative stated that the primary information is always in Engish with optional local language fields. It would be helpful if the RIPE database code was UTF-8 safe.

[AP63.2][RIPE NCC] Come back with a statement on what would be involved in making the RIPE database wholly UTF-8 safe.

D. Adding some privacy to RIPE DB geolocation (Richard Barnes)

See presentation

Main issue is that the geoloc: attribute is currently a point, which is not flexible enough.

Suggestion is to replace this with a URI, either a geo: URI or an external http: URI. This solves the privacy issue by removing private data from the RIPE database but is more difficult for the ISP to implement, of course. There is an XML schema for storing this sort of data and the intention would be to use this.

Support was expressed but a question was raised about whether the RIPE NCC could provide an appropriate proxy for the geolocation server. This might cause the same privacy concerns that were previously expressed and also the question might arise as to why we were treating geo-location data specially.

It was felt that we have to ask the community whether they want this additional feature. Some support was expressed for continuing the work, mainly to see if it was felt to be useful. It was agreed to bring it up at the plenary and then if necessary raise a formal policy proposal.

A question arose as to who would be allowed to modify the data. A suggestion was that the normal mnt-lower: hierachy would be acceptable.

[AP 63.1] [WW144] To take this up with the RIPE Chairman and see if this needs to go through the services WG, and also to ask the mailing list.

H. Input from other WGs and TFs

The Abuse Contact Management Task Force expects to propose something in the next two weeks which will be a required contact point for abuse in the database.

Z. AOB

Dave Freedman:
1. What happened to the password statistics? This was covered by the presentation above.

2. What about exposed password hashes? Should they be hidden? Brute force attacks are possible. Perhaps we need a proper problem statement? Is the problem that the hash is exposed, or is it just that people still use passwords? What about passwords in clear in email?
Using alternative transport mechanisms can mitigate this issue but it is generally an unsafe practice.
All of this points towards an incomplete problem statement.

3. Could we ensure that the issue of passing the Reg-ID issue to the Anti-abuse WG is addressed?
It seems to have not been passed over. The problem seems to be that it exposes business relationships. RIPE NCC pointed out that Reg-ID is internal but linked to Org: object.
The AA-WG chair was present and felt that the issue did not fall within the purview of his group.

4. There is an issue with non-orphaned Aut-num: objects to find what objects refer to it. There is currently no reverse lookup mechanism and this makes deleting objects difficult.

[AP 63.3] [Dave Freedman] Raise issue on the mailing list