RIPE 38

RIPE Meeting: 38
Working Group: Database
Status: 1st Draft
Revision Number: 1

Please mail comments/suggestions on:



Minutes for the
Database Working Group Meeting

RIPE-38, January 2001, Amsterdam, NL
1. Draft



Wednesday, January 24, 2001 16:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part 1: Joint Session with Routing-WG


Thursday, January 25, 2001 09:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part 2: DB-WG Meeting

P2-A. Administrative stuff (WW, chair)
. volunteering a scribe
Nigel Titley
. list of participants
. agenda bashing
The agenda was accepted (2nd draft).
. minutes distributed
Minutes as distributed were accepted.

P2-B. Actions Items
. Fwd domain object migration
Covered under "Operations update"
. IRT pointer facility
Covered in the agenda

P2-C. RIPE DB, operations update (RIPE NCC, Ambrose Magee) 20min

This presentation is available on the Ripe-NCC web site.
[RIPE-NCC please insert URL] http://www.ripe.net/

Of particular note is the very poor uptake of PGP. Everyone is
*strongly* encouraged to take up the offer of PGP licenses for
users of the database.

Queries have levelled off at approx 7/sec. Updates have dropped
from 21/min to 4.5/min, largely due to reduction in number of
domain objects.

Attention is drawn to the tuning of the batch queues to hold
back updates that include person objects, as these can involve
delays whilst the database is re-indexed.

Note the new RIPE DB FAQ.

It was noted that aut-num objects without maintainers will have
a maintainer object controlled by the RIPE-NCC added. Owners of
such objects will have to contact the RIPE-NCC to allow access
to their objects.

A question was asked about RPS-Dist. Ambrose confirmed that this
has not been worked on.

A question was asked as to whether we should migrate unreferenced
and unmaintained person objects. Concensus was that this could be
considered.

It was suggested that there should be a workshop on running a workshop
for NRTM users. It was felt that contact between the RIPE NCC was
sufficiently good that this wasn't a problem.

Concern was expressed about the use of unreferenced person objects
by other parties. It was thought that the use of unreferenced
person objects was not a problem, provided such objects had a
maintainer. There was *no* suggestion that all unreferenced person
objects should be deleted (or not migrated).

P2-D. CERT Object, IRT pointer (Wilfried Woeber)
. proposal
To allow a registry to register details of a CERT contact to
be associated with a group of resources (usually IP addresses).

Proposal is to add a new property mnt-irt to inetnum and autnum
objects which points to a new object, similar to a maintainer
object.

irt: NCC-IRT-RIPE
address:
phone:
fax-no:
email:
admin-c:
tech-c:
upd-to:
mnt-ntfy:
auth: {cryptpw |pgpkey }
mnt-by:
signature: KEY-REF- [single][mandatory]
encryption: KEY-REF- [multiple][mandatory]
changed:
source:

Note that the mnt-by property may be a self reference. The signature
and encryption properties may be used to send and receive email to
and from the team. Note that these values are not added to the local
key ring, but are simply used when communicating with the IRT Team.

. feed-back from TF-CSIRT Barcelona
Wide degree of support from some 45 representatives of IRT teams

A suggestion was made that the role object be extended to include
the extra properties of the irt object. Some doubt was expressed
as to whether this would allow the sort of extended whois search
that could be useful in the future for rapid tracking of incidents.

Wilfried will write up the proposal formally, and will submit it
to the WG for approval.

This proposal is being experimentally implemented in version 3
of the database.

P2-E. Unique Handle Proposal (RIPE NCC, Joao Damas)
This presentation is available at
[RIPE-NCC Please insert link]

This proposal attempts to address the problem of there being
no standard for a a globally unique handle proposal.

Some concerns were expressed with the problems of deleting objects
which are referenced elsewhere. One answer to this is to say that the
customer is responsible for their own data. However this removes
the ability to maintain consistency on object deletion.

Also need to address the question of reusing these unique names (do
we or not?), and whether or not to have a central registry.

A spurious question was raised over the use of the dash in the
unique handle and possible confusion with AS-macros. It was pointed out
that all AS-macros start with the string "AS-" which enables them
to be easily spotted.

Next step would be for the proposal to be fleshed out and presented
at the next ARIN meeting. [AP Joao Damas]

P2-F. Followup on Re-Implementation/Migration TF
(Wilfried Woeber) 15 min
This presentation was made to the Routing WG session and may be
found at [RIPE-NCC Please insert reference here].

The first cut over date is April 23 2001 (at which point updates
may be made in RPSL). Final cut over is in October, when the database
will be running fully in RPSL.

If any RIPE-NCC customer wants to delay this cut over, then a well
documented and substantiated technical case must be submitted at least
a month before the cut over. Such a case will have to be very strong
indeed, as a number of other initiatives are being held up by the
delay to the cutover, and more than a year's notice has been given.

The RIPE-NCC has been asked to make a first formal release of the new
database software and will do so, even if bugs remain.

A suggestion was made that RIPE NCC should make recommendations on
how to properly specify external references. It was decided that this
was a possible work item for the future but not immediately relevant.

PI.Y. Input from other WGs
.LIR WG
Proposal from the LIR working group allowing the status field
to have a value of lir-allocated. This has the suppport of the
LIR WG, and was accepted as a formal request. No objections
to the RIPE NCC being asked to go ahead with this.
[AP Joao Damas]

PI.Z. AOB:
. Legacy address space
Migration of these address objects from the original ARIN
database. ARIN is in the process of arranging for the provision
of in-addr.arpa servers for legacy address space. For addresses
which are in use in Europe, these will be transferred to RIPE.
Problems occur where a record exists in both the ARIN and RIPE
databases. A decision needs to be made which one to drop (there
are about 1000 objects falling into this category). A suggestion
was made to compare the timestamps, and also to publish a
list of the objects in dispute. It was decided to throw the
question to the mailing list as a first attempt to get an
answer. [AP Wilfried Woeber]

. Referential integrity override
How to overide the DB checks on updating person objects which
have objects referring to them. This has to be handled manually
at the moment. The suggestion is to allow a special update
mechanism. There was some suggestion that the removal of the
name as a primary key could solve this, but this was rejected
due to the possibility of typos when typing in a handle. It
was pointed out that the simple solution is to delete the object
plus all the referencing objects and then re-create them. Some
people felt that this was a clumsy approach.
[AP Karsten Schiefner To write to RIPE-NCC specifying the problem]