Minutes RIPE #16, DB Working Group

  Dear all,

  I just recently submitted the draft minutes for the DB-WG meeting 
  (jointly produced by Daniel am me) to Anne.

  Any comments welcome!

  Wilfried.
----------------------------------------------------------------------

Report from the Database-WG Meeting at the 16th RIPE Meeting, Amsterdam
-----------------------------------------------------------------------

0.	Additions to/modifications of the agenda

The proposed agenda was accepted.


1.	The new Database Software

Marten Terpstra provided a detailed report on the current state of the
DB-Software, both from a software point of view as well as from the
deployment point of view. The slides for this presentation can be found in
the presentations directory in the RIPE document store:
ftp.ripe.net:ripe/presentations

The new software is in production use since Friday September 10th and until
now there have not been any major problems.  During the discussion it was
again stressed, that the current implementation is built to do syntax checks
according to the object description and not according to common usage
practice.  The RIPE NCC welcomes suggestions as to where the syntax checking
needs to be changed.

Currently objects with illegal schema are deleted from the database.

One of the things discussed was how to avoid a possibly large number of
bounced submissions. One way of doing this is to obtain (part of) the new
software to do the checking locally. The beta-version of the software is
available, although it probably makes more sense to wait for the official
software distribution which will provide a dedicated syntax-checker.

A syntax checker daemon at the NCC was also suggested to remove the
requirement to run the software locally. A template generator was suggested
as well. This needs more discussion on the mailing list.

The NCC has run a syntax check on the whole database and was asked to make
the syntax error output available.

Daniel Karrenberg gave an overview on the "Authorization and Notification of
Changes in the RIPE-DB" proposal. It was decided to implement it as proposed.
Proposals on how to better support the distribution of the update process are
very welcome.

The discussion of implementing "guarded attributes" revealed concern about
the possibility to delete an object that has a guarded attribute. It was
agreed that the implementation will not delete any object as long as guarded
fields are present. This will force removal of guarded fields from the object
before the delete operation is accepted. The database is NOT keeping track of
"pending deletes", thus the delete request has to be submitted again after
removal of the guarded attribute(s). The NCC will look into ways to notify
guardians of failed deletes. The originator of the delete request will of
course be notified.

The procedure to convert existing information into guarded information (eg.
aut-sys: for the network object) was agreed as follows:

	- the NCC moves the information from the database to the guardian
	  files

	- initially the NCC is the guardian

	- as soon as possible, responsibility for the files is transferred to
	  the real guardian(s)


2.	Database (and Software) Documentation

The documentation will be structured to consist of

	- Object Definitions and general background information, 
	  by WW and NCC and available before the end of 1993

	- Software Documentation,
	  provided by the NCC asap

	- Maintainer's Guide (for eg. the Local-IRs) 
	  additional input and support is expected from the Local-IRs and
	  others

	- Secondary Server Guide
	  additional input and support is expected from the Local-IRs and
	  others

The Objects Definition and the SW-Documentation get priority, in the listed
order.


3.	Unique Person Handles

Given the growth of the database, it is urgent to distinguish person objects
for people with the same name!

After another round of thorough discussion it was decided that RIPE suggests
a global scheme to the InterNIC. One of the possible solutions is to reserve
a sub-range of the NIC handle space for RIPE allocation, eg. XY3000-XY5000.
If this approach fails, then WW and the NCC will propose a unique identifier
scheme for RIPE (aka "RIPE Handle").


4.	Objects Review and Proposals

The proposed CLNS routing object (dom-prefix:) was presented by Henk Steenman
and accepted. Some minor loose ends how to check for syntax and maybe
semantics of the hexadecimal strings that are the CLNS address-prefixes have
to be ironed out (Henk Steenman and Tony Bates).

The long-standing proposal to build a "Resource Object" was formally
withdrawn.

Then the discussion moved on to agree on how to make a smooth transition
from ripe-60 to the ripe-81 format to describe the routing. The steps are as
follows:

	- as soon as the guarded fields are implemented, ripe-60 entries will
	  no longer be accepted.

	- ripe-60 information is converted to ripe-81 format.

	- when there are no longer any operational dependencies then all
	  ripe-60 data will be removed from the database.

Jean-Michel Jouanigot is the focal point for the ripe-60 --> ripe-81
transition coordination.

Also the gateway: field for the network objects was confirmed to be obsolete
and can be removed from the databse.

5.	DB Exchange format(s) and procedures

The circulated document about the agreed interchange format was briefly
reviewed. Everything seems to be in place to actually start exchanges with
the InterNIC. There was consensus that this has a very high priority.
Currently the recommendation is not to try to get the various databases in
sync manually.

6.	DB usage conventions and recommendations

Quite some time was spent to discuss the connect: attribute of the network
object. It was agreed that the only well-defined value is LOCAL. This attribute
should eventually be obsoleted. Later it was noted that it is currently
mandatory and should be made optional after one round of mailing-list
discussion.

However, there is a need for the functionality, maybe the community: approach
is the right way to go (eg. create community NSF). Still there is concern 
that some of the approaches that are obvious for "old hands in networking"
are not necessarily useful for the end-users. Maybe the tools coming out of
the PRIDE project can help to solve this problem. NCC to start the discussion
with a rough proposal before the next meeting.


7.	whois++ by Peter Deutsch et.al.

The whois++ project was briefly mentioned, although the DB group had too
little information to actually discuss the issue.

AOB

It was mentioned that there is a need for new tools to support the Local-IRs.
This needs more discussion on the e-mail list.


Action-List:
------------

Action 16.?:	NCC
Put together a consolidated distribution of the new DB software, including a
separate syntax checker for objects

Action 16.?:	Wilfried Woeber
Start discussion on the DB mailing list on new tools needed, eg. template
generator, syntax checker daemon at the NCC...

Action 16.?:	NCC
Make the error reports form the DB syntax check publicly available

Action 16.?:	NCC
Implement changes to DB procedures according to the proposal "Authorization
and Notification of Changes in the RIPE-DB" by Daniel Karrenberg

Action 16.?:	NCC
Implement changes to DB procedures for the guarded attributes according to
the agreement

Action 16.?:	Wilfried Woeber and NCC
Produce documentation about "Background, History and Object Definitions" for
the new database software before the end of 1993

Action 16.?:	NCC
Produce "Software Documentation" for the new databse software asap

Action 16.?:	NCC
To approach the InterNIC to agree on the use of a sub-range of the global
NIC-Handle space for RIPE usage

Action 16.?:	Henk Steenman and NCC (Tony Bates)
Implement the dom-prefix: object for CLNS routing, after tightening the
syntax definition and semantics of the CLNS-address hexadecimal string

Action 16.?:	Jean-Michel Jouanigot
To coordinate the transition from ripe-60 to ripe-81 format for routing
description

Action 16.?:	NCC
Try to actually get the synchronisation of the various databases going, using
the recently agreed DB Exchange Format

Action 16.?:	NCC
Start discussion on the mailing list by providing a first proposal how the
functionality of the badly defined connect: attribute could be replaced (with
the target group of the end-user in mind!) by using eg. community: and other
forthcoming tools from the PRIDE project

----------------------------------------------------------------------