db-wg

Download

db-wg@ripe.net

February 1995

1 participants
1 discussions

draft minutes, DB-WG, RIPE #20
by Wilfried Woeber, UniVie/ACOnet 07 Feb '95

07 Feb '95

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(a)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(a)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(a)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 --------------------------------------------------------------------------

1 0