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-an... 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 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