Draft Minutes RIPE21, Database-WG

  This is the draft minutes for the DB-WG meeting at RIPE 21 in Rome.
  They are quite belated (and probably full of typos), but unfortunately
  nobody volunteered this time to act as a scribe...
  
  Comments, corrections, additions -as always- very welcome.
  Wilfried.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 	Draft Minutes: RIPE 21, Database-WG
	Rome, 8.5.1995
	Chair: Wilfried Woeber, Scribe: Wilfried Woeber
	------------------------------------------------------

0.	Administrative stuff

  Unfortunately nobody volunteered to take the minutes. I had to guide
  the discussions and to take the notes at the same time. Thus these
  minutes are probably not as comprehensive as we are used to. Apologies.

  The agenda was accepted as proposed, without changes.


1.	DB-SW review

  David Kessens, RIPE NCC, reported on the current state of the database
  software and the environment at the NCC for providing maintenance and
  doing development work.

  Activities since RIPE 20 (as Marten and Tony having left the NCC/PRIDE
  Project) centered on becoming familiar with the software, performing
  bug fixes and implementing minor extensions, like the "network update"
  feature whois -U and whois -tv (for template verbose).

  Other aspects worth mentioning:
  . reverse lookup technology
  . hierarchical authorization (initially for domains)
  . referrals
  are being researched and estimates for the necessary implementation
  efforts are obtained.

  David confirmed that the official distributioin kit available
  (anonymous FTP) at the NCC always contains the most recent fixes issued
  and additions.

  For more details please refer to the slides supporting David's
  presentation which are available from the RIPE NCC FTP Server in the
  presentations directory
  
	ftp://ftp.ripe.net/ripe/presentations/ripe-m21-david-DB-REPORT.ps.Z

  Merit is also working on the databse software and has produced some
  tools. These things are available from:
  
	ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet


2.      Security

  While there was no concern regarding the functionality and usefulness
  of the authorisation methods already implemented (mail-from:, crypt-pw:)
  there is a need for even stronger authentication of updates.

  PGP seems the way to go, although there is still quite a bunch of open
  questions and a need for logistic (e.g. key distribution) development.
  It is not clear at the moment whether this should be integrated (DB,
  RIPE NCC) or be provided by mechanisms outside the scope of RIPE.
  
  SURFnet reported it's intent to use the RIPE-DB for routing
  configuration as soon as PGP would be available to provide the data
  reliability necessary. Others expressed strong interest, as well.
  
  Merit (LJ) did part of the work already to provide PGP authorisation
  for the email addresses in updates.
  
  Comments from the group stressed that it is essential to *not* mix the
  concepts of authentication and of encryption. Encryption is a logistic
  and/or legal problem in some regions.

  The group is requested to persue this aspect on the relevant mailing
  lists.

*Action on David Kessens and Wilfried Woeber:
	Investigate the deployment of PGP for the RIPE Database and to
	draft a proposal.


3.	Review of beta test for RIPE-Handles 

  The method for generating RIPE-Handles was discussed once again, there
  are still open issues when trying to fully automate handle assignement
  because this would require both a DB-commit function as well as require
  the modification of submitted objects on-the-fly. The group did not
  resolve this issues, thus the current procedure (finger) remains in
  place. 

  It was noted that the scripts involved should be made available to all
  interested parties.


4.	External interfaces

  There is an on-going discussion (in the light of more than one
  organisation using the RIPE DB-SW now) on how to keep the various
  databases in synch. One of the ideas is to accept updates for each and
  every database on all interfaces, to analyze the "source:" attribute
  and then to automatically forward the update to the database as
  indicated by "source:". While this is probably quite interesting, it
  might not always be what the users intend.
  
  The alternative is to reject updates when submitted for the "wrong"
  "source:". This is the safe way.
  
  To meet the need of regularly transferring updates from one database to
  (an)other(s), a method using FTP and providing "deltas" is investigated.
	
5.	Input for and review of objects

  Due to the scheduling of the working groups, there was no input at the
  DB-WG meeting. 

  A proposal to expand the internet-router object to describe Mbone
  routing was circulated after the meeting, as drafted by the Mbone
  WG.

6.	AOB

  None. 
  Thus the meeting was closed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
WW. 2.6.95