RIPE 48

• content to the Chair of the working group.
• format to webmaster@ripe.net.

Database WG Minutes RIPE48, Amsterdam 5th and 6th May 2004

A. Administrative Matters
- scribe (Nigel Titley, FLAG Telecom + Frora)
- list of participants
- announcements
- agenda
Accepted
- minutes
Accepted
- "remote participation" coordination (if needed)
No requests
- meeting schedule for 2005
Thoughts on whether we will be able to manage with only
two meetings a year. Please feed back to WW144

Outstanding Actions

43.9 RIPE NCC To track outdated references to the IRRToolSet on the web
and correct them. [Complete]
45.5 RIPE NCC To document proposal on organisation object and re-circulate
on mailing list. [Complete]
45.6 RIPE NCC To collate responses (to organisation object) and make a start
on implementation. [Complete]
46.3 RIPE NCC Add reverse lookup feature for key-cert objects.
[Complete]
46.5 WW Coordinate with RIPE NCC to prepare a document summarizing
basic assumptions about the use of the database.
Presentation at RIPE-47 by WW144. [Ongoing]
47.1 RIPE NCC Set a deadline for the commencement of work on prototype
server code, taking into account the likely availability
of standards.[Ongoing, will be making announcement in a few weeks]
47.2 Randy Bush, Niall O'Reilly Create a short proposal on setting up an appropriate scheme
for a simple abuse contact (either "abuse" or "abuse-c")
[Covered by presentation, complete]
47.3 RIPE NCC Write a document properly documenting the use of the IRT
object for reporting abuse. [Ongoing]
47.4 WW To send note to DB WG mailing list to ask how many are using
the DB software, and on what platform. [Done, but no response, ongoing]

B. DB Operational Update (Shane K., RIPE NCC)
Presentation on RIPE web site

1. The Organisation object has been created and deployed
2. DNS is now built from the database
3. NONE authentication is now removed.

C. ERX Phase 3 (Leo V., RIPE NCC)
Presentation on RIPE web site

All /8 and /16s are complete. Work must now start on the /24 radioactive swamp.

D. Value "ZZ" for country: attribute (Engin G., RIPE NCC)
Presentation on RIPE web site

After discussion there was no real consensus for approving this proposal. The whole
business of making country: optional needs to be raised with the Address Policy
working group

[AP48.1 RIPE NCC] Raise the issue of making country: optional with the Address
POlicy working group.

E. CRISP/Joint-Whois status
. Joint-Whois report (Shane K., RIPE NCC)
Presentation on RIPE web site

RIPE NCC has not done work on this, in accordance with the wishes of the DB WG
but other RIRs have seen this as useful and work has started on it in the LACNIC
RIR, with support from APNic who will provide the test environment.

[AP48.2 Shane Kerr] To publish the requirements on the DB WG list.

. report by Andrew Newton, VeriSign
Presentation on RIPE web site

Note: The CRISP protocol is actually called IRIS, hence the name of the presentation

IRIS is an XML based protocol, specifically for use by registries of Internet resources
(not just address registries). IT has a wide range of authentication mechanisms which allow
proper authorisation. Referrals are properly handled. An prototype client, PIMMIT,
was demonstrated.

Some concern was expressed over how much additional operational overhead would be
imposed by the IRIS protocol. The response was that the overhead is not excessive.
Additional concern was expressed over the use of XML. The response was that prototype
clients and servers already exist, and that there are a plethora of tools available
for processing XML. The CRISP WG has been at pains to avoid inventing new technology,
but has largely used existing building blocks.

Fears that underlying databases would have to be modified were also raised and placated.

F. support for works of art (Nigel T., FLAG TC)
. poetry | haiku | ???
Presentation on RIPE web site

It was noted that without internationlisation in the character set, adoption in
the AsiaPAC region is unlikely.

[48.3 NT13] Proposal should be clarified and the minor issue of tech-c in the poetic-form
object clarified.

G. irt: / abuse: [60+ min]
. proposal by Niall O'R. & Randy B.
No Presentation, but later discussion

. statistics by Marco H., Niall O'R. and Ulrich K.
Presentation on RIPE web site

. next steps? (WW144)
No obvious consensus on mailing list. Suggested that the mailing list suggestion be
implemented to run along side the existing IRT mechanism.

Concern was expressed about the manadatory requirement for a PGP object in the
IRT object. The CERT community seems to be of the opinion that the PGP attribute
may be made optional.

The issue of what the database returns is also a problem. The database should return
an IRT object by default.

The point was made that the vast majority of spam complaints come from tools and that
the tool writers were amenable to using IRT.

The real problem is to remove the number of email addresses that are returned by
a database query and make it obvious which addresses are actually appropriate to
receive complaints.

Concern was expressed that if the data model was not correct, then retrieving the
data in any meaningful form will not be possible. The reply was that the proposal
could be considered as an intermediate step to a proper solution involving the
IRT object or something similar.

The discussion meandered off to consider social engineering to encourage
intelligent use of the available tools and data. This was agreed to be a laudable
aim but outside the scope of the WG

[AP 48.4 Randy and Niall] To refine existing proposal to take into account the
discussion during the session and try and acheive consensus on the mailing list.

[AP 48.5 RIPE NCC] To implement whatever consensus is reached on the mailing list regarding
abuse contact.

[AP 48.6 RIPE NCC] To change DB behaviour to return IRT object

[AP 48.7 RIPE NCC] To make the PGP attribute optional on the IRT object

H. RAToolSet & RPSLng (WW144)
. usefulness/consistency

Some comments have been received that these tools are sometimes difficult to use, and the
parser can return different results under different conditions.

A few members of the WG present have used the tools.

It was noted that the gcc, bison etc version make a lot of difference.

The main issue is that there seems to be no response from the maintainers to problems.
The development model seems to be moderately broken. Suggestion to put it in Sourceforge
or something similar. The response to this was that the RIPE NCC software team really
doesn't have the resource to devote a fulltime (or even part time) maintainer to the
toolset. A question is that is it reasonable to try and support it on the range of
platforms and compilers out in the wild?

It was felt that if the WG felt this was important, then it should mandate the RIPE
NCC to either properly maintain it, or to seek a better development model. The RIPE
NCC is currently storing up patches and then applying them in batches just prior to a
release. This is probably not applicable to the environment in which we find ourselves,
where protocols and OSes are changing so fast.

The possibility of a complete re-write was raised. Although this is probably not an
option the rewrite of the most used parts is a possibility.

[AP 48.8 RIPE NCC] To raise the issue on the appropriate mailing lists and seek advice
on change of development model.

[AP 48.9 RIPE NCC] To apply all available patches to RAToolset etc, and to start a
rewrite in ANSI C

Y. Input from other WGs

See item F

Z. AOB