RIPE-38

Minutes - Routing and Database

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