The following was waiting on top of more than one desk
(on mine eventually ;-) - again causing undue delay.
Please accept my apologies.
Wilfried.
------------- Cut along the dotted line -----------------
Database Working Group
Minutes of meeting, 28th January, 1998
at RIPE XXIX, Amsterdam, Kingdom of the Netherlands.
(!!! => Action Point).
The meeting began at 14:00. Wilfried Woeber chaired.
1. Administration.
AMRM acted as scribe. JS sent unsolicited (but not
unwelcome :-) ) notes to WW and AMRM after the meeting.
CO agreed to become scribe while AMRM was swapped out to
give a presentation.
The proposed agenda, circulated previously, was agreed; no
changes were made.
The draft minutes of DB WG at RIPE 28 had been previously
circulated. Comments were welcome on the mailing list.
2. The RIPE Database; an update on NCC activity.
(A.M.R. Magee)
Person & role data on the ftp site
-> now controlled by an AUP => restricted access,
still available on request, but based on an
agreement with RIPE NCC, signed by a contact person.
New release of the RIPE DB software
v.2.1.1 available, runs on perl 5.004
RPSL -> report to Routing Wg
DSTF (DB Sec Task Force)- > report to plenary
Some bug fixes
-> route object bug fixed
New DB Code
- design has begun
- current functionality, new code
- scalability
- report from Maldwyn Morris later
DB Consistency Project
- State of the Database Reports
-> report from the students later
- Prevention
-> new syntax checks; being implemented
- Clean Up
-> user education, new tools to be published
State of DB reports
- feedback welcome
-> frequency, appearance, .....
Database Statistics
- number of DB objects is doubling approximately every 8 - 10 months;
- now 750K objects
- number of DB updates slowly increasing, with major spikes every
6 - 8 months
-> possibly TLD administrators doing a "clean-up"
- number of DB queries gradually increasing,
the growth is modulated by a short-term (~ 2 months) fluctuation
now more than 2.2 x 10E6 queries per month
ripe-dbm
- mail bounces make the most mail
-> new objects created in the DB
-> these objects have a "notify" attribute which references
an e-mail address which is not set up
-> mail bounce to <ripe-dbm(a)ripe.net>
- users are asking <ripe-dbm> for help before reading ripe-157
(AMRM swapped back into scribe).
* DB consistency project; State of the DB Reports
- WW introduced Kurt Dirnbauer and Horst Koenigshofer;
he explained their role in the RIPE NCC as stagiares from
the FS, Wiener Nieuwstadt.
What is the DB consistency project ?
Kurt Dirnbauer briefly described the RIPE Database Consistency
Project, refering to the report written by students from the
Vrij Universiteit van Amsterdam (and described by CO at the DB WG
at RIPE 27).
He said that the goal of this project is to remove the inconsistencies
in the Database; e.g. make person references more reliable
He pointed out that the RIPE DB is not a commercial DB;
it is a "hand-built" database. This has advantages (e.g. portability)
and disadvantages (not relational).
He then showed an example of a State of the Database Report and
a graph of one of the tables of data (using sample data).
Technical Details
Horst Koenigshofer then discussed the details of his program. This
program takes the data and index files of the RIPE DB as input. It
appends its output to existing files which contain the output from
a previous run of the program. These files contain the numbers of
each type of inconsistency.
He said that at present, when there are 750K objects in the DB, that
his program needs approx 4hrs on a PC (133 Mhz, 2 GB disc, 32MB RAM).
Thus, his program will need 12 hours when there are 2 x 10E6 objects in
the DB next year.
Thus, improvements are planned: rewrite part of program and/or upgrade
the hardware.
Christian Halbe asked about the use of the output of the State of
the DB reports. CO replied that reports to individual object
managers would be available in the future. CO went on to say that
clean-up tools for objects managers would be provided; the
problem of who has the authority to change invalid objects would
be addressed.
Christian Halbe asked about plans to prevent further pollution of
the RIPE Database. CO said that new syntax checks are defined;
they will be implemented.
WW asked whether the problems were because of structural
inconsistencies or restricted modifications ???
Carsten Schiefner asked whether or not open access to the DB should
be disallowed i.e. why should anyone with an e-mail address be able
to create/update/delete objects ?
WW replied ???
CO said that there existed an authorisation model for registering
domain objects and IP address assignments; currently, a model is
being developed for the Routing Registry. Thus, if all three models
are in place, a general model for authorising DB updates could be
deployed.
WW pointed out that the modification of existing objects can be controlled
and suggested that we make this mechanism more secure. There is already some
control with the "mnt-lower" attribute. However, there is no control on
the creation of person or role objects similar to the creation of a mntner
object (which requires the manual intervention of the RIPE NCC). In the
past, _everyone_ was welcome to register useful data in the RIPE DB.
Should this change now ?
* DB software Re-Engineering
Maldwyn Morris, RIPE NCC discussed the existing code of the RIPE DB and
outlined proposals for re-engineering it.
He described the current system as one with well known interfaces, heavily
used and "it works, but ....".
He outlined the problems with the code: it is unspecified, undocumented,
under commented, messy, and based on the functionality of perl4; i.e. the
excellent new feature available in PERL5 are not used.
He went on to say that the new version will be carefully planned: the code
will be specified, documented and commented. API layers will be specified which
will be coded in an appropriate language. External software (e.g. a
database engine) will be used where appropriate.
He described the workplan to develop this new software, but stressed
that the existing functionality will be preserved; the goal here is
not to introduce new functionality, but to make it easy to do so.
AMRM pointed out that the software was specified in RIPE documents. MM replied
that the functionality of the existing code was often different from the
specification in the RIPE documents.
Jake Khoun asked about goals for optimisation, e.g. increased speed. MM said
that such improvements were under consideration. Jake Khoun suggested that
Merit and RIPE NCC might combine appropriate pieces of DB software. Both he
and MM agreed to continue the discussion off-line.
CO stressed that this what was being dsicussed was new code with existing
functionality; the RIPE NCC would continue to add new functionality to the
existing code.
WW commented that the existing code _is_ working and still performing
satisfactorily. He himself would like to see a commercial database with
the facility for shadow copies, ftp-copies etc. available all over Europe.
He remarked how the NCC had reached the limit, in terms of volume, of
the existing code. These limits are set by PERL and the operating system.
It was pointed out that other organizations use similar code and link in
external software. The NCC will consider this.
* Other Developments
!!! Jake Khuon and WW agreed to send a proposal for specifying new
functionality to the RIDE mailing list. Jake indicated that the RIPE
NCC code was used, but with a small modification to the process of
handling as-macro objects. He went on to say that Cengiz had promised
that the new version of the RA Toolset will support this.
!!! Jake promised to send another pointer to the mailing list saying
where the documents about this exist.
CO remarked that the RIDE project had stopped, and with it a way to
formulate the exchange of database information. Thus the IP registries
are unable to exchange data. There is a major problem with the RIPE
NCC being able to exchange data with ARIN; this problem may be solved
at the level of an IETF WG or direct contact between IP registries.
* Proposal for online registration of person objects (or role objects)
to be done during a DNS domain registration
(WW was swapped out of the chair to give a presentation on this topic;
CO was swapped into the chair).
The overall goal is to register a DNS domain.
Currently there are two ways to do it, both are clumsy. The first
method involves do some processes locally: e.g. rip apart the
request for a domain and get the person object; then check if the
person object is in the RIPE database.
The new concept: do not mix DNS domain registration, and person/role
registration.
Start with person/role objects. Then submit domain object (or inetnum,
or whatever), i.e. the referenced objects first, then the referencing
objects. Currently, the only interface to the RIPE DB is based on
e-mail. This is store and forward => slow (unreliable ?).
The proposal on the table is to replace (or supplement ?) the e-mail
interface with a process that will generate an new nic-hdl immediately.
I.e. a separate communication path between update machine of the RIPE
DB, and some application at the user side. So no disruption during the
overall registration process occurs. This should include syntax checks
and semantic checks (distributed, i.e. not only at the RIPE DB site,
but also locally). There should at least be support for security, even
if it is not implemented:
- checks on the identity of the person sending in the update
- responses should be signed
- before anyone can use this path, they must first make a case
to the RIPE NCC.
WW felt that these three security checks were going to come anyway.
WW presented this technical proposal and showed a sketch of the outline
of the process. He pointed out that local checks could be implemented
in the client.
rough sketch:
client local server DB master
java-script <----> cgi bin <----> DB software
local http tcp
Most of the analysis done at the local side, additional testing done
by the RIPE DB.
WW said that some developement work had been done; a Java applet had
been developed (for the client).
Prototypes already exist, others are invited to also use it, if the
community thinks that it is worthwhile.
WW then asked the group for input .....
Christian Halbe said that this system was exactly what his organisation
needed. They had a similar system, but it was based on e-mail and it
was slow.
Achim Patzner said that this system would be too late for his organisation.
CO (as temporary Chair of the WG) thanked WW for his presentation. CO
went on to say that some of the security issues mentioned earlier were
being addresses by the DSTF (Database Security Task Force), including
the definition of a secure database. CO invited input.
Overall, there was support for this idea in order to develop a
simple user interface.
* Input from other WGs
JS summarised the result of the Routing Work Group meeting, which
was held earlier that day. In particular, JS mentioned:
- authorisation:
discussed both at the last IETF meeting and at the Routing
Working Group that morning;
updates should to the database should be authenticated;
- more security:
misuse/malicious use should be prevented
- the Routing Registry is part of the overall registry; there
is security on the IP numbers, but not on route objects.
- more input for Database Working Group ??
* AOB
none.
* Close.
RIPE XXIX DB WG Action Points
-----------------------------
1/. Jake Khuon and WW agreed to send a proposal for specifying new
functionality to the RIDE mailing list.
2/. Jake promised to send another pointer to the mailing list saying
where the documents about the RAToolset exist.
------------------------------------------------------
