draft minutes, DB-WG, RIPE #20
- Date: Tue, 07 Feb 1995 22:06:01 MET
Dear DB-WG and David!
This is the draft of the minutes for the Database WG.
Again many thanks to Andreas Knocke for providing me with the meeting
notes in due time.
David, I'd be grateful if you could do a spelling and sanity check on
the text below. I'm writing too many minutes in a hurry these days :-(
As always, any comments welcome.
Best regards, Wilfried.
PS: I'm off-line from 9.2.95 until 3.3.95,
thus I'll be unable to respond to comments during the next 3 weeks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Draft Minutes: RIPE #20, Database WG
1. Administrative stuff
The agenda was agreed upon as proposed.
Andreas Knocke (DE-NIC) volunteered to act as scribe for the meeting.
2. The "new" database software: review, future
Report by Marten Terpstra:
The new software had been announced at the RIPE 19 meeting in Lisboa.
After being available for external testing it was put into production
in October 1994.
Since then some bugs were fixed and some (small) syntax checking
features were added, users of the database should not have noticed the
change - mostly.
Recently the database was moved to a decicated (new) machine (Sparc/5,
whois.ripe.net).
As a general remark - Marten urged everybody to use the generic names
for accessing the individual RIPE NCC services because a number of
services (ftp, whois, www) have already been moved to different
machines. Renumbering the RIPE network also required to renumber the
machines.
Documentation and future development of the software package shall be
done by Daniel Karrenberg and David Kessens - due to the fact that
Marten is leaving the RIPE NCC right after this meeting.
Finally the official release will be available from
ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.00.tar.gz
Other aspects of general interest:
Time stamps (as requested by Merit and agreed upon in Lisbon) have not
yet been added. Maybe Merit is going to add that functionality. Still
there should only be one common version of the software.
Hashed comments (# starting after white space) are allowed in any
object submitted to the database although comments are *not* stored in
the databse itself. While there was some discussion of allowing
"end-of-line comments" this was dropped to avoid breaking scripts.
Still an empty line (only white-space) is required to separate objects
from each other.
3. RIPE Handles
RIPE Handles are necessary to uniquely identify person objects with identical names
and are required for the exchange of information with other databases,
e.g. the InterNIC. Handles created for use in the RIPE environment
database are very similar to the well-known NIC-Handles but have the
string "-RIPE" appended to make them unique amongst different registries.
Given the more distributed model of operation, the APNIC is going to
append the relevant ISO 3166 country codes for the same purpose.
Unique RIPE Handles can be obtained by fingering whois.ripe.net:
finger handle.XY@localhost
where XY is the initials of the person's name to have a handle assigned.
E.g. to request a handle for a given John Doe just do:
finger handle.jd@localhost
which returns something similar to:
First free handle: JD5-RIPE
Using this (interim) method of obtaining unique handles introduces a
possible race condition. This is yet to be solved.
There are still some loose ends when a person object is updated to get a
handle field. Occasionally there may be duplicate person objects created.
In this situation the out-dated object can be simply deleted.
RIPE Handles are currently considered to be in field test.
On a more general level it was proposed to investigate the legal aspects
of storing person-related information in a publicly accessible database.
4. External interfaces
The SWIP (Shared Whois Project) for exchanging information amongst the
(Regional) Registries requires unique handles.
The rwhois project (see RFC 1714) - Mark Kosters of InterNIC briefly
reported on the resources available (he is working on it in his spare
time). A final beta version might be available at the end of Q1 1995.
5. Review of objects and links
Inverse lookups:
Inverse lookup is very desirable easily to find out where all the
references to a given object (persons, but maybe inetnum objects as
well) are coming from.
Action 20.DB1: on the RIPE NCC, to do an implementation analysis.
"status:" attribute
Geert Jan de Groot explained that this attribute was indeed required
for keeping track of address assignments. Marten had agreed to
implement it on the fly to support a new tool for NCC internal use.
As implemented, the acceptable values for this attribute are
"Delegated" "Assigned" (and "Reserved").
The little sketch below depicts the model:
total delegated delegated assigned
address to RIPE to local-IR to customer
space 193/7 19?.*/16
I
I
I / I / I
I / I / I / I
I/ I/ I/ I
I\ I\ I\ I
I \ I \ I \ I
I \ I \ I
I
I
6. Meta objects
Contrary to the current recommendation the person object is "mis-"used by
a couple of entities to describe role accounts and similar things.
Daniel Karrenberg agreed that this can indeed be useful, even if he
opposed this use in the past. However "admin-c" for an object still has
to point to a real person object.
Action 20.DB2: on HAvard Eidnes to write up a proposal with input from the
Local-IR WG and the EOF (European Operators Forum)
7. Input fromt the DNS-WG: domain object
In addition to a brief report on the decisions within the DNS-WG, Piet
Beertema elaborated on the information scheme for keeping track of
domains domains under the TLD ".nl" w2hich has been implemented. Piet
intends to remove all objects other than the one for .nl itself. This
proposal calls for a forwarding pointer in the RIPE-DB that links to the
machine where the data is actually available (the name server for .nl).
Questions discussed and issues arising from this proposal:
- How can compatible schemas be maintained? With the updated domain
object this can be achieved, although the representation for persons
are different - tools have to "keep this in mind".
- The referral mechanism
. The rwhois package is not yet ready for production use and has to be
extended for CIDRization (whois++ the same),
. The RIPE DB software currently lacks the concept of forwarding
queries (comparable to proxy forwarding in BIND) for forwarding to
other whois servers.
There was a general consensus that the domain object is a very good
candidate for starting a pilot to distribute information to the
environment where it is maintained.
With regard to person objects, the allocation registry and the routing
registry, the RIPE database should not be modified right now (production
use and automatic configurations!).
Action 20.DB3: on the RIPE NCC to investigate (as time permits)
distribution of the domain information and to investigate a "private"
approach for referrals.
Havard Eidnes reported on a tool to check the primary zone file for .no
against the registered domain objects.
Action 20.DB4: on Havard Eidnes to publish this tool for the benefit of
other top level registrars
8. AOB - any other business
None, thus the WG meeting was closed.
Z. Report on an out of band discussion for the minutes
"An additional, informal BOF happened just before the lunch break -
inheritance of authorisation was proposed and discussed for hierarchical
objects which would resolve a common question: the authorisation of
allocations from a delegated block and of the addition of subdomains
within a registered top level domain."
--------------------------------------------------------------------------
Wilfried Woeber : e-mail: Woeber@localhost
Computer Center - ACOnet :
Vienna University : Tel: +43 1 4065822 355
Universitaetsstrasse 7 : Fax: +43 1 4065822 170
A-1010 Vienna, Austria, Europe : NIC: WW144
--------------------------------------------------------------------------
|
you are here: RIPE -> RIPE Maillists > Archives
