Skip to main content

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


RIPE 35 Database Working Group Date: Thursday, Feb 24th
Location: RIPE NCC, Amsterdam


Slot#1 ,9:00

    A. Administrative Stuff (Wilfried Woeber, Chair)

    B. RIPE DB, operational update (NCC: AMRM, 20 mins)

    C. A short review on the maintainer mechanism
    - are there any security concerns?

    D. A "smarter" whois client

    E. (tentatively) Is there an interest to register CERT/IRT-related info?

Slot#1, 11:00

    F. Status of reimplementation project (NCC, JLSD 20mins)

    G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW, 15 mins)

    H. Do we need/want a DB review/re-structuring TF
    - future topics of interest
    - I/O with other WGs
    - Logistics

    Y. Input from other WGs

    Z. AOB

Chair: Wilfried Woeber
Scribe: Engin Gunduz
Participants: 65

A. Administrative Stuff

The proposed agenda agreed with an addition of item "D".
Scribe appointed, Engin Gunduz.

B. RIPE DB, operational update (NCC: AMRM)

(presentation is available at )

AMRM provided an update on:

    - Performance
    - Software status
    - Reimplementation
    - Other RIPE DB services
    - ripe-dbm mailbox
    - Operational issues

C. A short review on the maintainer mechanism

WW: 1. There was a useful presentation by Olaf (Kolkman) about PGP. DB is an example for PGP being used with weaker authorisation methods.
Has anybody used PGP? (4 people raised their hands).

2. CENTR activity. We've been talking about removing domain objects from whois db.
Do you have any timing for this?

AMRM: This is a political question, please ask this to Joao.

D. A "smarter" whois client

WW: Technical framework: NCC has offered mechanism to referral mechanism. This is working nicely. The central whois server has to act as a proxy. But, whois client needs to know Now, we can have a client who tries to find a TXT field from DNS, so that it would know which whois server to query. We may ask NCC to implement this.
What do you think? Should NCC spend resources for this?

We will chase this issue.

Peter Koch: There was some intelligence in one of the old RIPE whois clients which enabled it to query whois-<tld>

AMRM: We don't know about this.

WW: Background: It's becoming more frequent that people are abusing network resources. Now, how would you find out whom to contact in such cases? Proposal: We can have a mechanism to point the user to a proper point.
Would anybody be volunteer for a blueprint?

AMRM: In roles, we have "trouble" attribute. This is for such cases. But I think you mean a more sophisticated thing.

Former chair of FIRST: You must be in FIRST organisation.


Slot #2: (11:00)

F. Status of reimplementation project (NCC, JLSD)

(presentation is available at )

Jake Khoun: There are three-five groups trying to implement RPSL. Isn't it possible to create a subgroup to coordinate activities?

JLSD: We tried to bind people together.

WW: This is a good input. We can found (a top level, not local) an open forum. RIPE NCC employees can follow ARIN & APNIC mailing lists.

WW: More than 50% of the objects in the RIPE whois DB are not exactly related to RIPE, being an IP registry.

JLSD: It will be hard to find a solution to this. Domains are growing extremely fast. We are trying to find a solution. We have talked to DENIC & Norwegian domain registry, they are going to move their objects. They expect to get their domain objects in approximately 3 weeks, and person objects in 2-3 months. We are happy to help them. So, I just ask for coordination here. If you want to delete your domain objects, please let us know.
We have referral mechanism, we can use it.

Jake Khoun: I had a proposal: The behaviour of whois server could be to search all sources, instead of only RIPE source, and, to stop at the first match.

David Kessens: I think the main reason for current default behaviour was to save computer resources. But I don't think that this is the case anymore. We must be able to change the default behaviour. But I don't like the idea of stopping at the first match.

G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW)

WW: Who is in general think that they will be hit by new interfaces? (Three persons raised their hands, Jake Khoun, Nigel Titley, and one more person).

WW: So, could we count on you to form a Transition Task Force?

JLSD: We can use db-beta list for this.

WW: We will get back to you about this before May.

JLSD: Agreed.

WW: Another point: There was a bug report on security of RIPE DB software.

JLSD: The mntner "feature" was already there. Finally the community say that it is a bug. But at this point of time, there is no point in fixing this in the old DB.

A participant: Is it difficult to fix this?

JLSD: The question is, should we divert the resourses to it or not.

Jake Khoun: The actual fix would be to put proper mntners to objects.

WW: There was a report on some unauhorised changes to objects. So, nobody must have unprotected objects in the DB. Now, should we tell the users that they must use at least CRYPT-PW, but not MAIL-FROM?

Dmitry Morozovsky: RIPN does not put unprotected objects in their DB. Can RIPE do that with the reimplementation?

WW: We must have the social engineering first, I think, e.g., putting a text in ACK messages which says that the MAIL-FROM authorisation is not good enough.

AMRM: Some users just don't read ACK or notification messages.

Jake Khoun: There should be enough emphasis on using CRYPT-PW & PGP instead of MAIL-FROM.

Action Point: on NCC to draft a proposal.

H. Do we need/want a DB review/re-structuring TF

WW: I'm looking for someone to help me documenting our achievements. I don't have time to do proper documentation. Please any volunteer find me in breaks.

WW: What should be the future of the DB WG? I'd like to get some input on what should we have as a charter? What are we supposed to do. Please think about your personal priorities, and provide input.

Apologies for no minutes.

Y. Input from other WGs

No input.


There wasn't any other business.

Chair thanks to participants and closes RIPE35 DB WG meeting.