draft minutes, DB-WG, RIPE #20

  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 at whois.ripe.net

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 at whois.ripe.net
	
	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 at CC.UniVie.ac.at
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4065822 355
  Universitaetsstrasse 7         :  Fax: +43 1 4065822 170
  A-1010 Vienna, Austria, Europe :  NIC: WW144
 --------------------------------------------------------------------------