May 1999 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Tagging of IP adresses / Application-Database
by Nacamar AS Guardian 07 Jun '99

07 Jun '99

Hi, at RIPE-Meeting 33, the issue on the agenda of the lir-wg of "Tagging of IP adresses and ANTI SPAM" was rejected. Partly, because this has been implemented by Paul Vixi, http://maps.vix.com/dul Further, it was felt that these tags should not be an addition to the IP-Objects, because it has a much broader range of possible applications. So, the issue was handed over to the db-wg to think about a new application-registry. Such an application-object could look like: >>> location: [mandatory] [single] [primary/look-up key] app-type: [mandatory] [single] [primary key] app-subtype: [mandatory] [single] [primary key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] <<< Location would be a range of IP-Addresses or maybe a hostname, app-type a value/keyword like "nameserver", "dialin", "mail" etc., app-subtype a more detailed code for the application, like root-nameserver, tld-nameserver, cc-nameserver, etc. Details to be discussed... Then descr, contacts etc, just the usual stuff. Technically, this shouldn't be too hard, but the main questions remain on the administrative side: - who would use this database, and for what purpose (Anti-SPAM, better route-flap-dampening ...) - who should insert/maintain the contents - how to determine if the contents are 'legal', e.g. come from the 'owner' of the mentioned ip-ranges/hosts - what to do if someone protests against some contents, or claims damages because of some contents Just to spark a bit of discussion... Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Robert-Bosch-Str. 32 D-63303 Dreieich +49 6103 993 0 Voice Germany +49 6103 993 222 FAX gurt(a)nacamar.de ------------------------------------------------------------------- Titanic 12 - Hiroshima 45 - Tschernobyl 86 - Windows 95 - Silvester 99

3 4

Proposal to change default source search behavior in the whois server
by Jake Khuon 27 May '99

27 May '99

Currently, the RIPE whois server returns a result from a single-source (RIPE) search by default. One needs to pass a -a flag in order to obtain multiple-source returns. Because of this behaviour in conjunction with the necessity to allow a "defaulted" query to return inetnums, the architecture of the database is limited to a single source. For those organisations who may wish to run their own registry and participate in mirroring, this poses a considerable issue. I propose that the behaviour be modified so that the default would be to return a single-match first-hit from multiple-source search. That is, a query will return only one result but it will search through the source search order and return the first match it finds rather than simply stopping at the RIPEdb. -- /*====================[ Jake Khuon <khuon(a)GCtr.Net> ]======================+ | Network Statistics Engineer, NSM/Net-Eng /~ |2 () |\| ~|~ | @ |2 | | VOX: +1(408)328-4828 Fax: +1(408)328-4806 _/~ G L & B A L C E N T E R | +============[ 1154 East Arques Avenue, Sunnyvale, CA 94086 ]============*/

1 0

2. Draft, proposed agenda DB-WG meeting RIPE-33, Thu.,May 6
by Wilfried Woeber, UniVie/ACOnet 05 May '99

05 May '99

Dear WG participants, dear WG-Chairs, here's the final draft agenda for the DB-WG meeting. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 -------------------------------------------------------------------------- Proposed Agenda for the Database Working Group Meeting RIPE-33, May 1999, Vienna, AT 2. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing - review of action items B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - current status of PGP deployment C. DB SW Re-implementation (RIPE NCC) - progress, milestones/roadmap, deployment, documentation - operational aspects, mirrors, clients - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . others? D. I-D draft-ietf-rps-auth-??, -rps-dist-?? (??) - RIPE region requirements/comments - any progress E. DB Consistency Project (RIPE NCC) - status update F. IPv6 issues - what are the loose ends? . Routing registry (RPSLng ?) . Objects . IP-registry X. IETF report(s) if any :-) Y. Input from other TFs/WGs - LIR-WG: application specific registries? DUL, Root-NS, TLD-NS,.... - DBsec TF mission accomplished? mandate for continuation? next activities, if any at all? Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 5-MAY-1999 13:46:59

1 0