RIPE 41

Minutes for the
Database Working Group Meeting

RIPE-41, Jan. 14-18 2002, Amsterdam, NL

A. Administrative stuff (WW, chair)
. volunteering a scribe
Nigel Titley took the minutes
. circulate list of participants
. agenda bashing
. Several items received, agenda modified.
. Status of minutes and actions
. RIPE 40 Minutes to stay as draft for 2 weeks. Comments to the mailing list.

B. DB Update (RIPE NCC, N.N.) (Andrei)
. Operations report (available from the Ripe web site)
No substantial changes in database contents since last meeting.
Database still growing, mostly inetnum and person.
Unreferenced and unmaintained person objects are growing again
and need to be sorted out.
A strange query pattern with a large increase of content data query
This has been manually blocked and tracked down to a runaway
script which was fixed.
60% of valid queries are for inet-num objects.
80% of updates are new objects.
. Communications with DB users
http://www.ripe.net/ripencc/faq/database
db-help@ripe.net
Both useful sources of help.
. bug fixes, re-writes, platform compatibility
. RPSL object library now provides functions for object parsing
and syntax checks. Has been rewritten and can be used standalone.
Written in C but perl wrapper also available.
Binary download available.
. status LIR-PARTITIONED PA (PI) now available and facilitates
LIR IP address management. Mulit-level assignments are no
longer necessary. Avalable in beta.
. irt object now available (see below) Available in beta.
. DB code available for Linux, Solaris and FreeBSD
. future plans
. Auth checks across multiple databases
A proposal will be circulated for examination.
. Real time updates
No proposal, but is being considered. Views on the priority
of this requirement would be welcomed.
. Automatic database cleanup
The current proposal (remove unreference and unmaintained
person objects) needs some changes. Notifications should be
sent before deletion. Referenced objects should never be deleted.
However, maintained objects will now be removed. This is slightly
controversial as it removes people who could be useful even though
they don't own any objects. The fact that such objects are still
being created points to obsolete scripts still running. A suggestion
was made that checking the maintainer attribute of the maintained
but unreferenced objects would result in a few culprits being
identified.
The WG gave a mandate to the RIPE NCC to continue with the cleanup
process.
. Prototyping RPSL extensions (ipv6, multicast)
. Further improvment of DB software
. Documentation(!)
. Main events
. Migration to RPSL/v3 completed
. New whois web interface is now online.
. DB Consistency and Statistics project is now online
. RRCC is resumed (RIPE-201)
. IRRToolSet support, documentation and bug fixes. Please
comment on requested features.

[AP-41.1 WW] To send list of proposed updates to mailing list for WG
members to vote on. Deadline 3 weeks.

A proposal to allow referencing external objects (particularly as-sets)
in "import" objects was received from C&W. It was agreed to discuss this
on the mailing list.

[AP-41.2 C&W] To send their proposal to the mailing list for discussion.

C. DB consistency and Statistics project (RIPE NCC, Can Bican)
. Motivation
. Data gets outdated
. Early software was more tolerant
. Goals
. Provide suggestions to make data more consistent
. Trace the inconsistencies
. Provide necessary tools
. Checks
. Unreferenced person/role (25%)
. Duplicate objects (3%)
. Various invalid inetnum objects (overlaps, no status, hierachiacal)
. Weak maintainer authentication (none and mail-from)
. Results
These can be obtained by sending to auto-dbcon@ripe.net

D. IRT object implementation (RIPE NCC, Andrei)
. implementation report, last-minute adjustments
. Provides contact information of a CSIRT
. Provides public keys
. Can be referenced from inetnum objects
. New argument (-c) to whois client
. how to use and promote the new features?
. Create irt object pointing to CSIRT
. Add mnt-irt attribute to inetnum
. Use whois -c to find the most specific inetnum pointing to
to irt.
. The auth attribute is used to add the mnt-irt reference.
. The object will be created manually, but the authentication
mechanism needs clarification.

[AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object.
[AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate
objects.

It was noted that many spam complaint scripts trawl the DB for anything
that looks like an email address. There seems little chance of educating
the writers of such scripts. The chair of the Spam WG commented that this
was a real problem.

It was suggested that the DB should not allow an IRT object to be created
with weak authentication methods, but Abdrei felt that this was a bad
idea and that if an irt object was created with auth "none", then it
probably was not being created by an appropriate person.

E. Universal Whois Project (Andrew Newton, VeriSign App. Res.)
http://uwho.verisignlabs.com/

. Needs of addressing information as it relates to domains in whois=
.
Needs have been limited to those who loosely "administer" the internet.
Some conflicts have been noted, especially in different legal frameworks.
Emphasis has been placed on providing the mechanisms not setting the
policy. Here to collect further requirements.
Questions still arise as to how ro traverse information repositories.
Suggestion is to use DNS SRV attribute.
Still not decided on how to handle structured queries as there is no
universal standard, apart from RPSL for routing registries.
The primary users will be network operators.
Question of whether to use port 43 or not. New port would allow a fresh
start, but does the internet really need a new application transport.
Requirements draft will be submitted to IETF at end Jan 2002.
. Overview of two technical solutions.
. LDAP
. XML
both available on the web site and are draft RFCs.

Some discussion took place on the issue of unique handles. The proposal
is to use URLs as handles, but this is not yet set in stone.
Comments are welcome.

F. DataBase documentation for the "average" user
. Requested by Ruediger Volk
Who could not be present.
. Problem statement
Current queries return all the objects related to a query which
can confuse the naive user.
. Proposal
An end-user document or FAQ is suggested.
. How to proceed?
APNIC has an FAQ already which may be useful.
Simplified output from the web page
The issue was raised that selectively omitting returned attributes
from a whois query was not possible whilst still remaining RPSL compliant.
However, this would not be an issue for a simple web interface or for
a more complex whois client. Comments on improvements in this line
would be welcome by the DB team.
A proposal that the template object could indicate which attributes
may be omitted was received.
[AP-41.5 WW] To put together a group to put together a short guidance
document to guide reference document writers. This team to include Ruedige=
r.
[AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and adverti=
se
to the db-wg list.
A suggestion from the RIPE NCC for a number of simple web interfaces to
cover various scenarios: "Im being hacked", "I'm being spammed" etc.
Another suggestion was to use a different port number for a "simple"
reply.
=09
G. "changed:" "organisation:" Objects re-visited (tentative)
. No discussion

H. Input from other WGs
. Tools WG
. Web interface to whois is now available. Any patches should
be sent back for folding in to the master.
ftp://ftp.ripe.net/tools

Z. AOB:
. Database Mirroring
ISPs need to copy all DBs into one place in order to do queries. Mirroring
protocol is there, but currently undocumented. Could this be documented
at some time? Also mirroring is very primitive and needs to be more
selective. It was suggested that the use of a "private" tag could be used =
to
limit mirroring all objects.
There also seems to some "stickiness" in the mirroring protocol
which causes the secondary database to always be one transaction out of da=
te.
The RIPE NCC responded that this was deliberate, to prevent a bad transact=
ion
crashing both primary and secondary.
[AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness".
[AP-41.8 C&W] To formulate their proposals on the list for discussion.
[AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational
requirements of using it.
. Remove MAIL-FROM in maintainer object
. Start by nagging maintainer owners to remove MAIL-FROM attributes
. Then disallow updates of any maintainer object with MAIL-FROM
auth attributes.
. Introduce reverse indexing on IRT irt-mnt auth and signature keys.
Note that this cannot be done until the MAIL-FROM auth method is removed.
. Implement MD5 password authentication
[AP-41.10 RIPE-NCC] Provide nag message to maintainer owners
[AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication
[AP-41.12 RIPE-NCC] Look at general password authentication methods