RIPE 38

R I P E 3 8 A M S T E R D A M
Joint Session DB and Routing
24-Jan-2001 Draft Minutes

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)
[ The presentatino is available at

http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-andr

ei/index.html ]

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 [email protected]
RIPE-181 updates are still possible and still go to [email protected],
but are autmatically converted to RPSL
- 14-May-2001: exchanging mail addresses
[email protected] only accepts RPSL updates
RIPE-181 updates are still possible but now go to [email protected]
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
[email protected]


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