RIPE 57

• content to the Chair of the working group.
• format to [email protected].

RIPE 57 (Dubai)
Thursday 30 October, 09.00 - 10.30
Chair: Nigel Titley
Scribe: Anand Buddhdev (RIPE NCC)
Jabber monitor: Franz Schwarzinger (RIPE NCC)

A. Administrative matters

• Welcome
• Scribe selection: Anand Buddhdev (RIPE NCC)
• Finalise agenda: agenda accepted
• Approval of minutes from RIPE 56: accepted
• Review of action list: Jos Boumans (RIPE NCC) to present first, and cover outstanding action list in the presentation.

B. Database Update - Jos Boumans, RIPE NCC

AP54.3: Mandatory MNT-BY on all objects
Done for all forward and reverse domain objects. Person and role objects will be done by December 2008.

AP54.7: Deprecation of rev-srv
DB schema needed changes. Will be done at the same time as the mandatory MNT-BY for person and role objects.

AP54.6: Clean up unreferenced objects
About 25% objects are unrefenced. Currently we're in monitor mode. Deletes will start in late November. We'll start with 100 deletes a day. Users are urged to enrol in white pages* to avoid being deleted.

See description of white pages in presentation

Nigel asked about AP55.1 because there was no mention of it in the presentation. Jos said that it discussed at RIPE 56, and the AP is
still ongoing.

Nigel expressed concern about loss of email updates.

An attendee asked what will happen to poetry objects when the contact is removed?

Denis Walker (RIPE NCC) responded that the RIPE NCC would have to consider poetry objects as operational.

C. Data Protection Task Force Update - Jochem de Ruig (RIPE NCC)

Nigel noted that AP56.1 appears not to have found its way to the Data Protection Task Force. Malcolm Hutty will speak to Jochem later about this

There were no further questions.

D. Mirroring of the RIPE Database - Denis Walker (RIPE NCC)

The presentation summary is a recommendation from the Data Protection Task Force to not allow mirroring of the RIPE DB, or the other way round.

Questions:

Randy Bush asked if the RIPE NCC is strictly discussing the registry data, or the routing data?

Denis replied that he was talking about registry data.

Randy stated that he had a problem with this and asked if the RIPE NCC was going to shut down whois from outside the EU?

Denis said that he was only talking about bulk access.

Randy said that he needs to be available in the RIPE Database for routing data and that he needs to create his data in more than one database.

Ruediger Volk said that the fact that auth data and routing data is in one database is a feature. Removing bidirectional mirroring seriously interferes with the practice of generating policy for people who are currently doing this. There are work-arounds, but currently it is easy because of the mirroring. People will have to create new ways of accessing this data, and it will be a pain.

Denis said that there isn't actually a single database. We have the -a option to ask the query server to query RIPE Database plus the mirrors.

Ruediger Volk said that router filters are generated from one database, such as RADB. After this change, the RIPE Database won't be in RADB.

Andrei Robachevsky (RIPE NCC) clarified that the group was talking about personal data. Route objects don't contain personal data.

Ruediger asked if NIC hadles were also personal data?

Denis responded that yes NIC handles are also (unfortunately) personal data. Therefore they can't be exported.

Nigel said that perhaps we can export just a routing database, and not the registration database.

Jos said that LACNIC does NOT allow mirroring. Secondly, the RIPE personal data is mixed in with routing data.

Ruediger said that perhaps when data is exported, we can have a filter that defines which objects are legal, and which not. This should be simple to do.

Randy said that the Task Force should talk to the Routing Working Group for more information.

Nigel said that this issue probably needs to go back to the Task Force to figure out what can and cannot be legally imported/exported.

Andrei added that this issue is also about mirroring other RIR data. LACNIC does proxying for example.

Nigel said perhaps we should proxy.

Andrei responded that the joint whois does not proxy.Jos said that joint whois has been discussed. Proxying (rediecting) queries is okay, as it does not involve exporting personal data. So proxying would be legally okay. This solves the incoming problem, but perhaps not the outgoing problem.

Y. Input from other working groups:

Nigel asked if any more discussion was needed about ASPLAIN.

Andrei said that the IETF has approved ASPLAIN. The Database Working Group should make an action point on the RIPE NCC to implement this.

Ruediger asked the RIPE NCC to make sure that current client software does not break when ASPLAIN is implemented.

AP57.1: Action point on the RIPE NCC to implement ASPLAIN.

DOMAIN: Objects in the RIPE Database - Peter Koch (as DNS WG co-chair)

The NCC looked closely at all non-reverse domain objects. Most ccTLDs have a single object with a refer attribute. Some have additional stuff. There is incomplete, random or inconsistent data in 2nd level objects and even some 3rd level objects. Very few ccTLDs actively maintain their entries.

During the CENTR meeting, held just before RIPE 57, there was no objection to the removal of ccTLD objects.

The DNS WG sees no continued benefit from keeping forward domain objects in the RIPE database. However, TLDs relying on the service should be given help with migrating their data.

AP57.2: The RIPE NCC should come up with a schedule to phase out forward domains. Maintainers will be expected to remove their objects. There should be a cleanup after the deadline. Co-ordinate early with ccTLDs using the database actively.

No questions were asked.

Z. AOB

There was no other business.