Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 36

RIPE-36 Minutes for the Database Working Group Meeting
Date: May 2000
Location: Budapest, HU

A. Administrative stuff (Wilfried Woeber, chair)

  • scribe
    Nigel Titley volunteered to take the minutes


  • raw scribe notes distributed
    Wilfried had not had time to process the raw notes from RIPE 35, but these were circulated in lieu of full minutes.

  • help offered by
    - Nigel Titley,
    - Ulf Kieber

    Wilfried asked the WG if they were happy to accept the help offered by Nigel Titley and Ulf Kieber. Nigel would help with the PR and documentation side of the group, and Ulf will help to co-ordinate the working group. He received approval from WG on this issue.

B. RIPE DB, operational update (Andrei Robachevsky, RIPE NCC)

    Andrei Robachevsky gave an operational update on the state of the RIPE DB. Amongst the many statistics that he presented it was noted the very large number of domain objects, mostly from the .de domain. It was explained that these objects would be shortly devolved to the DE-NIC whois server, and plans were currently being formulated to perform this move with minimum disruption to the RIPE community.

C. DB Software Re-Implementation (Joao Damas, RIPE NCC)

    Joao Damas gave a short presentation on the progress of the DB Software re-implementation project.

D. Report on Certification Authority activities (Paul Gampe, APNIC)

    Paul Gampe gave a very interesting presentation on the use of X509 certificates for authentication when updating the APNIC database. The following points were noted:

    - Training at the next RIPE meeting might be useful, to provide a view of X509 vis-a-vis PGP. There appears to be a degree of convergence between the two systems.

    - It was noted that it will be soon possible to sign X509 keys with PGP signatures and vice versa.

    - The main objection to using X509 is the cost of the commercial licenses. The first phase of the implementation will sort out licenses for users. Much cheaper (free) approaches are on their way.

E. Activity Plan for next year!

    It was noted that input to the RIPE-NCC activity plan was needed before September. Suggestions received from the WG included

    - Use of X509 signature for authentication (as per APNIC)

    - Support for other character sets than ASCII. (Joao noted that the new code is 8-bit clean, but that there is problem wit the reproduction of character sets. The best he felt able to do was to track progress by other sources, and to keep the code clean).

    - Removal of further domain objects from the database. The problem being that existing applications must not be affected. It was suggested that the RIPE-NCC could offer help to other ccTLDs to set up their own whois databases. It was suggested that we ask CENTR to produce a regular report and to try and get domain objects shifted out of the DB. [AP: Wilfried Woeber and Joao Damas]

F. Input from other WGs

    - EIX-WG would like an object in the DB to describe IXs. It was also suggested that a peering contact in the aut-num object could be useful. There was some support for both these proposals and it was suggested that a formal request be made to the WG by email.

    - Routing WG. No further input had been received from the Routing WG re native multicast. It was felt that this would soon need looking at. The Routing WG needs to add an entry to the RPSL Draft.

G. AOB

    - A suggestion (Joel Rowbottom) was made to use XML for registration templates. Suggestions as to how to do this would be gratefully received.

    - A suggestion to use a mail-to authentication scheme was received from Michael Battilana (IANA). The idea being that agreement to proceed with a modification would be obtained via a token and confirmation from a know mail mail address.
    It was agreed that this was not very easy to do as it is stateful and could lead to DOS attacks on the database.

    - A brief update was given on CERT/IRT-related issues (WW144/Jaques Schuurman). Ut was suggested that a pointer be added to inet-num object to point to the IRT role. Anyone interested in this work to contact the WG.