RIPE 38

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

Chairs: Joachim Schmitz, Wilfried Woeber
Scribe: Engin Gunduz
Participants: 97


Joint Session of Routing and Database Working Groups

Due to the importance of the subject, and the overlap in topic, the chairmen
of Routing and Database WG (Wilfried Woeber) decided to have a joint session
of both WGs. Joachim introduced the audience to the session, and chaired it
together with Wilfried.


E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min)

Andrei gave an overview of what to expect for the migration to the new
RIPE database. He began with asking who would be affected by the migration,
and the answer is: everybody.

Reasons are
- RPSL format
- new access control
- new database format
- new version mirroring protocol

He supported this by a set of examples, and made suggestions on how to
prepare for the migration, depending on which usage group a database user
belongs to
- query users
- update users
- adaptation of scripts
- near real time mirroring

Following that a schedule was presented which summarized the proposed final
transition dates
- 23-Apr-2001: switching to the RPSL database
Queries return RPSL only
Mirroring follows new format and rules at whois.ripe.net, port 4444
RPSL updates go to auto-rpsl@ripe.net
RIPE-181 updates are still possible and still go to auto-dbm@ripe.net,
but are autmatically converted to RPSL
- 14-May-2001: exchanging mail addresses
auto-dbm@ripe.net only accepts RPSL updates
RIPE-181 updates are still possible but now go to auto-181@ripe.net
and are automatically converted to RPSL
- 15-Oct-2001: RIPE-181 updates are no longer possible

The crucial date is the first one. It will not be possible to go back after
that date. The RIPE NCC has prepared a vast set of aides to assist in the
transition, and to get used to RPSL format. All details are available at the
RIPE-181 to RPSL transition web page
http://www.ripe.net/rpsl

The presentation led to a vivid discussion, in particular whether the
first transition date is too early or too late.

Ping Lu was suggesting to move the dates further into the future because
- they are using a lot of off-line tools
- the downstreams need to be educated
He later explains that he himself would transition rather earlier than later
but he is worried about their vast customer base.

Joachim pointed out that the transition should not be delayed because RADB
is already running RPSL since quite some time, making it more complicated
for people using both RADB and RIPE. Moreover, he thought that someone had
written some tool to perform at least in part some back conversion from
RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be
possible
for a limited number of objects. However, such tool never was available.

Christan Panigl reminded the audience that the idea had come up to supply
a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before
the transition to the RPSL database, essentially before 23-Apr. The audience
wants to have this tutorial parallel to the next RIPE meeting. However, this
would delay the first transition date into May.

A quick poll showed that 10 people in the audience knew RAToolSet, and that
actually 2 were using it in conjunction with RADB. It obviously makes sense
to have a tutorial

-> action 38.R1 on Wilfried Woeber and Joachim Schmitz
to organize a RAToolSet tutorial at the RIPE39 meeting

Ruediger Volk points out that a transition very shortly after the tutorial
does not make much sense. He also stresses that he objects against
postponing
the transition, because other transition projects within his company have
already been delayed due to the not yet factual transition with RIPE.
Jake Khuon agrees with Ruediger. He also points out that many of the objects
are doubly registered both in RADB and RIPE.

Joachim asked the audience who of them are actually using any kind of
automated tools in conjunction with the database, and it turned out that
these were more or less the same people who also knew RAToolSet.
Accordingly,
most of the people requesting a tutorial on RAToolSet do not need it right
now and are thus also not affected for automation. This decouples the dates
of when the tutorial will be held, and the transition to RPSL.

Consequently, even though these are only proposed dates, Wilfried suggests
to stick to these dates, and people who think that they have real technical
problems must speak up to the community to have those reviewed.

-> action 38.R2 on Wilfried Woeber and Joachim Schmitz
to send around the transition dates, get input from the community, with
a following decision on the dates

Ping Lu thinking of interaction of databases then brings up the topic of
global NIC handles. Wilfried explains that globally unique NIC handles are
not related to RPSL, or the transition to RPSL. He has it on his agenda
for the Database WG session tomorrow (25-Jan).


F. Report from the DB migration task force
(Wilfried Woeber, Andrei Robachevsky)

Wilfried reported that the DB migration task force did a review and besides
a set of questions identified by some active members of the user community,
the following open issues were identified
- Outreach
The RIPE NCC has taken every effort to notify all parties repeatedly
who will be affected by the transition. Disappointingly, the feedback
on these efforts has been small.
- Other items are
* broken PGP keys
* unprotected aut-num objects
* object names not compliant with RPSL
which were discussed in a short presentation by Andrei

Andrei gave a few statistics on those items, first on their efforts to
contact parties which need to be involved, and then on the open issues
where Joao Damas explained the proposed solutions.

- Broken PGP keys
The old PGP programs generated non-compliant PGP keys. Those keys will
be refused by version 3 software. It turns out that 7 out of 409 PGP keys
are broken.
The proposed solution is to delete the key certificates. This does not
affect security for a simple reason: If someone wants to apply a change
to objects protected that way, the software does not find the
corresponding key certificate, and thus rejects the update. The
party who wants to submit the change will then be required to contact
the RIPE NCC.
It was general consensus in the audience to follow that approach.

- Unprotected aut-num objects
In the past, it had become mandatory to have aut-num objects protected
by a maintainer. However, 119 out of 4008 aut-num objects still today
do not have a mnt-by attribute. So far, they enjoy a "special" protection:
Only ripe-dbm can modify them. Surprisingly, none of them was ever touched
in all the time since the original change of requirements.
It is still mandatory to have a maintainer with each aut-num object in
RPSL. The question is of how to proceed. The proposed solution is to
add a special RIPE NCC maintainer. By that way, no security breach is
opened, and no change compared to the situation today is introduced.
If anybody ever wants to touch that aut-num object again, they still
need to contact ripe-dbm.
It was general consensus in the audience to follow that approach.

- Reserved RPSL names
Quite a lot of objects in the database have names which do not comply
with RPSL rules. An example are 108 aut-num objects using the reserved
prefix "AS-" in the AS-name attribute, or 7 maintainer objects with
other reserved prefixes.
The proposed solution is to change the names prior to transition in
a way which still needs to be agreed upon. A suggestion is to contact
all parties who own those objects, and also publish them on appropriate
RIPE mailing lists.
It was general consensus in the audience to follow that approach.

Those results were taken to the Database WG.

Ping Lu raised the question whether there was the intention to implement
global maintainers. Andrei explained that so far all references must be
resolved locally.

Andrei also showed which OSs are currently supported for the database
software
o Solaris 2.8 (Intel & Sparc)
o Linux (RedHat, SuSe).
o FreeBSD
The inquiry from Wilfried showed that this list is accepted by everybody,
and no other OSs seem to be used by any company of registry, meaning from
that side no problems are expected. Wilfried asked the NCC to release the
database software for all platforms without putting too much effort into
performance tweaking for each individual OS, just assuring its overall
functionality.

Anybody who wants to participate in the transition discussion is free to
join the migration task force mailing list
reimp-mig-tf@ripe.net


Summary of Open Action Points from the Joint Session of DB and Routing

38.R1 on J.Schmitz, W.Woeber
Organize RaToolSet tutorial at RIPE 39
status: new

38.R2 on J.Schmitz, W.Woeber
Collect final community input on DB migration dates
status: new


Engin Gunduz, Joachim Schmitz, February 2001

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]