- db-wg - mailman.ripe.net

Top 100 Maintainers List 19991108
by RIPE Database Administration 08 Nov '99

08 Nov '99

1 0

Reminder: RPSL Transition
by Gerald Andrew Winters 29 Oct '99

29 Oct '99

A final reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net and email submissions to auto-ripe181(a)radb.net. In addition, between 11/1/99 and 1/1/00, RIPE-181 submissions will be auto-converted and folded into the RPSL database. Users need to be aware of this, as corresponding RPSL entries will be overwritten with the auto-converted RIPE-181 objects. You will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. During the changeover, the whois.radb.net DNS entry will be changed to point to the production RPSL database. Because of DNS latency, there will be a period of time when all resolvers have not received the new DNS entry IP address. During this transition period, some users may want to manually configure the IP address used by their query tools. The IP addresses of the machines will be: whois.radb.net 198.108.0.18 (RPSL queries) whois-ripe181.radb.net 198.108.0.11 (RIPE-181 queries) For further information about the transition to RPSL, see: http://www.radb.net/announce.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

RPSL Transition
by Gerald Andrew Winters 26 Oct '99

26 Oct '99

A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. RIPE-181 submissions made between 11/1/1999 and 1/1/2000 will be visible on whois.radb.net as RIPE-181 objects converted to RPSL. The objects will be converted every five minutes from the whois-ripe181.radb.net database. Availability of the database in both syntax languages will ease the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. fter January 1, 2000, RIPE-181 object submissions will no longer be accepted. Here is the full transition schedule: DATE CHANGE ---- ------ 9/1/1999 RADB begins production RPSL service and enters the final stage of RPSL transition. RPSL queries are available from whois-rpsl.radb.net and submissions may be sent to auto-rpsl(a)radb.net. RIPE-181 and RPSL databases operate in parallel. whois.radb.net and auto-dbm(a)radb.net default to RIPE-181. 11/1/1999 Default whois.radb.net and auto-dbm(a)radb.net addresses change to RPSL database. RIPE-181 queries still possible via whois-ripe181.radb.net and RIPE-181 submissions still possible via email to auto-ripe181(a)radb.net. auto-ripe181(a)radb.net submissions will be auto-converted to RPSL and mirrored to the RPSL database every 5 minutes. Therefore, auto-converted RIPE-181 submissions will be visible on whois.radb.net and corresponding RPSL entries may be overwritten. 1/1/2000 RIPE-181 queries and submissions are no longer accepted and the RADB RPSL transition is complete. RADB users can query RPSL objects by issuing the following query: whois -h whois-rpsl.radb.net Objects may be submitted by sending mail to: auto-rpsl(a)radb.net Users may also use the Web-based GUI interface at: http://www.radb.net/irrj.html RPSL RFCs and Internet-Drafts are available through: http://www.ietf.org/html.charters/rps-charter.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

Top 100 Maintainers.
by RIPE Database Administration 21 Oct '99

21 Oct '99

1 0

New DB release 2.3.1
by RIPE Database Administration 14 Oct '99

14 Oct '99

Dear colleagues, We have made available the new release of RIPE Perl database software at our fto site. You can find it at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.3.1.tar.gz Please find attached notes of the new release. Best regards, RIPE NCC DB Group ----------------- RELEASE NOTES for RIPE Database 2.3.1 This is a bugfix release with no new functionality added. There are some operational changes which should be transparent to the end user but ease the database maintenance and (dramatically) improve performance. SUPPORTED SYSTEMS ================= This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. CHANGES ======= Incorporated MAXLISTLENGTH and MAXSTRINGCOMPONENTS variables into the configuration file. They define the internal buffer sizes for reindexing; MAXLISTLENGTH defines the max length of the list of index entries, MAXSTRINGCOMPONENTS (name preserved for historical reasons) determines the number of entries for classless indices. Whoisd: added a 3 seconds delay before denied connections are dropped. In the inet6num objects, quads are zero padded to improve readability. Comparison of objects set to ignore the differences in number of whitespaces. BUG FIXES ========= Maintainer checks for dbupdate -T (test database) were not correct. Fixed setpriority parameters for whoisd {-L|-M|-m}. If invoked with wrong uid, dbupdate would fail silently. Now prints a message and exits 75. A range in class A ending with ?.?.?.0 would be changed to ?.255.255.255. Also fixed /32 ranges (beginning=end). PERFORMANCE FIXES ================= Turning splits and joins into a regexp substitution in key handling code decreased the CPU usage. Nic-handle generation algorithm takes 30-40 steps now instead of up to a few thousand.

3 2

Top 100 Maintainers List 19991004
by RIPE Database Administration 04 Oct '99

04 Oct '99

1 0

object definitions
by Chris Ottrey 04 Oct '99

04 Oct '99

Hello, Work here at the NCC on the Re-Implementation Project (RIP), is well under way. We have been looking closely at the existing definitions of objects incorporating them into our new design. We thought that now might be a good time for getting ideas on any changes in the object definitions that the wg would like to see. Eg. - "mandatory" mnt_by field in domain - "mandatory" mnt_by field in inetnum - "mandatroy" mnt_by field in person (instead of the current - "optional".) (Eg. to provide some sort of indication of how much protection users have against someone else deleting all their domains. Some users may not even realize that it is possible.) Existing object definitions can be found at: http://www.ripe.net/db/reimp/design/er/er_whois.html Chris. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= A ,-._|\ Chris Ottrey \_ / Oz \ At work in Amsterdam, \_,--._/ ottrey(a)ripe.net +31 20 535 4444 -=-=-=-=-=-v-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2 1

Top 100 maintainers list
by RIPE Database Administration 22 Sep '99

22 Sep '99

1 0

Maintainer report...
by Paul Rolland 21 Sep '99

21 Sep '99

Hello, Just one thing I'd like to point out : it seems that the database used to create the maintainer report is not sync with the 'live' db... I've been doing some deletion on Sunday, and got the Ack on monday Morning. Looking at the report generated this morning, refreshing, updating the pages again and again, I can still find the same 'mistakes' which are not in the live db (the update has really been processed). Am i missing something ? Regards, Paul Paul Rolland, rol(a)oleane.net France Telecom Oleane/Direction Technique/Directeur France Telecom Oleane/Technical Direction/Director -- Please no MIME, I don't read it - Pas de MIME, je ne le lis pas Please no HTML, I'm not a navigator - Pas d'HTML, je ne suis pas un navigateur "Some people dreams of success... while others wake up and work hard at it"

2 2

We think it may be interesting...
by Joao Luis Silva Damas 20 Sep '99

20 Sep '99

Hi, we have just made available some more operational information online for your convenience. Please see http://www.ripe.net/db/mrtg/whois.html Hope you find it useful. It uses the great mrtg tool. Best regards, Joao Damas RIPE DB Group manager RIPE NCC

2 1

report on nic handle reuse in the RIPE DB
by Joao Luis Silva Damas 17 Sep '99

17 Sep '99

Dear all, for your reading pleasure :-) This issue came up during the last RIPE meeting. Best regards, Joao Damas RIPE DB Group Manager RIPE NCC

4 3

RE: object definitions
by Wilfried Woeber, UniVie/ACOnet 16 Sep '99

16 Sep '99

>Subject: object definitions > >Hello, Hi Chris! [ nice to meet you! ] >Work here at the NCC on the Re-Implementation Project (RIP), >is well under way. Cute acronym, but don't get near Routing with that one :-) >We have been looking closely at the existing definitions of objects >incorporating them into our new design. > >We thought that now might be a good time for getting ideas on any >changes in the object definitions that the wg would like to see. > >Eg. > - "mandatory" mnt_by field in domain From a DB-WG's point of view, change requests for this one should be coming from the users of the Domain-Registry. I'd feel much more at ease if the request to change things would come from / at least be endorsed by the relevant WG (TLD-WG, probably?) > - "mandatory" mnt_by field in inetnum Likewise, just s/Domain-Registry/IP-Registry/ (LIR-WG?) > - "mandatory" mnt_by field in person This is probably something DB-WG can't push away to somewhere else :-) >(instead of the current - "optional".) > >(Eg. to provide some sort of indication of how much protection > users have against someone else deleting all their domains. Some > users may not even realize that it is possible.) In case we want to work on the awareness (first, even before deploying the new SW?), we could think about putting some sort of "(weakest/used) protection indicator" into the ack-messages? Something anlong the lines of: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following objects were processed. New OK: [inetnum] 193.170.2.0 - 193.170.2.255 protection: NONE Modified: [person] Spider Tarantula Woman (SPT1-RIPE) protection: ACONET-LIR-MNT, PGPKEY-DBC579D4 New OK: [domain] crack.ac.at protection: MAIL-FROM .*(a)cc\.univie\.ac\.at ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maybe this is not a bad idea, anyway? >Existing object definitions can be found at: >http://www.ripe.net/db/reimp/design/er/er_whois.html > > >Chris. > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > A ,-._|\ Chris Ottrey > \_ / Oz \ At work in Amsterdam, > \_,--._/ ottrey(a)ripe.net +31 20 535 4444 >-=-=-=-=-=-v-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Thanks for bringing this up, and could the other WG chairs please indicate their preference for where to deal with that? TIA, Wilfried. PS: Chris, I hope your question indicates that the NCC is already very far down the road with implemenetation and testing, rather than fixing that very early on for whatever reason? I hope the new SW design still allows for modifying these things by way of some site config facility? -------------------------------------------------------------------------- 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 __________________________________________________________________________

1 0

1. Draft, proposed agenda DB-WG meeting RIPE-34, Thu.,Sept.23'99
by Wilfried Woeber, UniVie/ACOnet 16 Sep '99

16 Sep '99

Attached please find the 1. draft for a proposed DB-WG agenda! As usual, additional input and comments are solicited! Please be prepared to see an update to that being circulated on the DB-WG list between now and just before the meeting. Looking forward to see many of you in Amsterdam, next week, Wilfried. Note to <Meeting(a)RIPE.NET> and <Webmaster(a)RIPE.NET>: Please use this version for the hand-outs and for the meeting web page. Thank you! -------------------------------------------------------------------------- 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, September 1999, Amsterdam, NL 1. Draft [ Note: for any updates between now and before the WG meeting, watch the DB WG Mailing List, please! ] A. Administrative stuff (Wilfried Woeber, chair) B. RIPE DB, operational update (RIPE NCC) C. DB SW Re-implementation (RIPE NCC) D. DB Consistency Project - presentation ((RIPE NCC) - discussion E. Birth of, and Life after the release of The New SW - migration/implementation planning (if any :-) - next development steps W. Do we need/want a DB WG review/re-structuring? - future topics of interest (workplan/charter?) - I/O with other WGs - logistics X. Report(s) Y. Input from other WGs - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 16-SEP-1999 13:17:19

1 0

Re: RIPE handles delay
by Wilfried Woeber, UniVie/ACOnet 15 Sep '99

15 Sep '99

Dear Vesa! => response to updates more directly related to the RIPE DB intended purpose => while still ensuring that others not so directly related will get => processed. = =This tactful comment probably means a turn to the right direction. =But I wish it was said loudly and clearly, maybe even as a complete =change in DB usage policy. We pay for address registration services, =please take the domain (non-rev-dns-related) objects elsewhere. To statr with I'd like to assure you that we are (sometimes painfully) aware of the issue(s) you'r point fingers at. Quite a bit of things have been achived already to allow us to move in the right direction in due time: Technically: the NCC already has implemented the WG-approved refer: attribute to allow referrals to "remote" autoritative servers for domain: objects. This is already being use by (a few) TLD registries, others are working towards that end. Logistics: CENTR was formed within the framework of the RIPE NCC quite a while ago to deal with TLD activites (or DNS issues in general). CENTR has meanwhile been incoprorated as a legal entity of it's own, and moved office to the UK. RIPE discussions: we have already (recently) started to discuss (both informally amongst the WG chairs, as well as within the various WG meetings) the issues with co-locating different registries within a single database environment (i.e. the IP-Registry, Routing-Registry, DNS-Registry). These issues are (amongst others) . authority for data and responsibility for data quality . access patterns ie.e. (updates vs. consumers, privacy, copyright) . providing operational resources As an aside, you are correct in stating that the NCC's main objective rests with the IP-Address, including reverseDNS and Routing Registry activites. But, at the same time, the creation of and support for CENTR and the DNS-related activites was agreed by the RIPE community and there was (still is?) a contract in place between the NCC and CENTR to have CENTR contribute equitably to the NCC's operational costs. I'm looking forward to continue this thread of discussion (within the DB-WG framework or somewhere else) as well as to corrections and amendments by the RIPE community and WG chairs, and/or from NCC staff. Best regards, and thanks for bringing this up (again) for consideration! Wilfried Woeber DataBase WG chair. -------------------------------------------------------------------------- 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 __________________________________________________________________________

1 0

Re: RIPE handles delay
by Joao Luis Silva Damas 14 Sep '99

14 Sep '99

Hi, we have been having a lot of trouble lately here at the NCC. Apart from some HW problems, that are now fixed, we are still receiving updates at a rate and in a combination that the DB can't presently handle in a fast way. All messages sent are queued and processed in turn. We are working on optimizing the software to handle these updates faster. Also we are going to deploy a queue control system to ensure a prompt response to updates more directly related to the RIPE DB intended purpose while still ensuring that others not so directly related will get processed. Currently we are processing the mails that were causing the problems with a lower priority to ensure an adequate service to the community. I will be presenting an in depth report on the situation next week at the RIPE meeting (DB wg). Shall the TLD wg also be interested in the some sort of presentation or overview I will be glad to present it. We have been reporting on the situation to this and other RIPE wgs and shall continue to do so. At this moment the situation is such that messages are being processed as in the good old days :-) Best regards, Joao Damas RIPE DB Group Manager RIPE NCC On Tue, 14 Sep 1999, Alfredo E. Cotroneo wrote: > Hi, > > For the last ten days or so we have noticed that replies for a new contact > handle to auto-dbm(a)ripe.net is taking much more than the usual 2-5 minutes > as it used to be in the good old times ;-) Although we request only a few > handles per month, a relly from RIPE takes now 10-20 hrs or more in some > cases, regardless of the time (day or night, week or week-end) when the > request is sent out. > > I have heard of some kind of explanation related to SW/HW upgrades at RIPE > and huge requests of handles being queued by some provider a few days ago, > however, can someone at RIPE tell if the situation is going to be solved > soon and when ? > > Unfortunately this is causing at least an additional 1+ day delay in the > registration of new domains at the Italian NIC, as IT-NIC requests that a > handle exists for each contact before the domain registration form is > submitted. Of course any comment from IT-NIC on how they can modify their > internal procedures to minimize such delays (i.e. by IT-NIC requesting a > new handle to RIPE directly) is also welcome. > > Thanks. > > > -- > Alfredo E. Cotroneo PO Box 11028, 20110, Milano, Italy > Phone: +39-335-214-614 (try first) / +39-02-266-6971 > email: alfredo(a)nexus.org fax: +39-02-706-38151 > >

2 1

hide the dates on Ripe Database
by roberto.bazan＠inycom.es 09 Sep '99

09 Sep '99

Hi, everybody, I'am new in the list , I would like to know, if can i hide Ripe Database's date ? Thanks in advance

1 0

RIPE database
by Jerzy.Pawlus＠cyf-kr.edu.pl 07 Sep '99

07 Sep '99

[ Moderator note: changed local-ir(a)ripe.net -> db-wg(a)ripe.net ] Anybody knows what is happening with RIPE database? I have sent my update 24 hours ago and they are not visible. Jerzy Pawlus

1 0

Top 100 Maintainers List
by RIPE Database Administration 06 Sep '99

06 Sep '99

3 2

Slow performance of Ripe DB ?
by Paul Rolland 06 Sep '99

06 Sep '99

Hello, It seems we are currently facing a performance problem on the RIPE Db, which started at least yesterday... I sent an update request dated : Date: Sun, 5 Sep 1999 15:43:46 +0200 and got no answer since... Since the updates requested are not processed, I guess that either the mail has not been received or the processing delays are getting quite high... Maybe this is to be related to the fact that the maintainer report is still not published... On a general basis, I have the feeling that since this report is being generated, response time of ripe db has been seriously impacted... Is this just a bad feeling ? Regards, Paul Paul Rolland, rol(a)oleane.net France Telecom Oleane/Direction Technique/Directeur France Telecom Oleane/Technical Direction/Director -- Please no MIME, I don't read it - Pas de MIME, je ne le lis pas Please no HTML, I'm not a navigator - Pas d'HTML, je ne suis pas un navigateur "We all want to change the world" - The Beatles - Revolution

2 1

Delay in processing updates
by Engin Gunduz 06 Sep '99

06 Sep '99

Dear Colleagues, Currently we have a long mail queue to be processed by the RIPE database. If you haven't received an acknowledgement for your updates, there is no need to send them again, all messages to auto-dbm have been queued. We are sorry for the inconvenience, Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Problems with this morning's results ?
by Paul Rolland 03 Sep '99

03 Sep '99

Hello, It seems that there is a problem with the results currently displayed on the Web in the Per Maintainer Inconsistency Report. OLEANE-NOC is mentionned to have 2908 NEVER_REFD, but it seems this is due to the fact that all the objects referenced in a .fr domains have been considered as NEVER_REFD, even though the domain seems to be in the RIPE DB. For example, we have Christophe Wagnon that is never ref'd, but it is used in the apore.fr domain. Regards, Paul Paul Rolland, rol(a)oleane.net France Telecom Oleane/Direction Technique/Directeur France Telecom Oleane/Technical Direction/Director -- Please no MIME, I don't read it - Pas de MIME, je ne le lis pas Please no HTML, I'm not a navigator - Pas d'HTML, je ne suis pas un navigateur "If you're not scared, you don't understand" - Mike O'Dell, VP UUNet Tech. Inc.

2 1

Sad news
by Joao Luis Silva Damas 27 Aug '99

27 Aug '99

Dear all, It is with great heart pain that I bring you some very sad news. Last Tuesday, our friend and colleague Roman Karpiuk suffered a terrible traffic accident while on holidays in his home country that has caused his death and that of his wife, Danka. The whole of the RIPE NCC is shocked after this event. I think I speak for the whole RIPE community if I say that we'll miss Roman and remember him as the joyful, creative and always ready to help colleague that he was. We shall always remember both of them with fond memories. Yours, Joao Luis Silva Damas RIPE NCC DB Group

1 0

Delay in processing updates
by RIPE Database Administration 25 Aug '99

25 Aug '99

Dear Colleagues, Due to an unprecedented series of major operational problems over the last few days, there are now many updates waiting to be processed by the RIPE Database. The waiting time for some updates has reached 24 hours. We have worked to fix this problem and the situation is improving. We expect the performance of the RIPE Database to be back to normal late tonight. In the meantime, we would ask you to be patient. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We realise that is causing some inconvenience to you, but we would appreciate your co-operation. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Marek Bukowy ____________________________ RIPE Database Administration.

1 0

Top 100 Maintainers List - 19990820
by RIPE Database Manager 24 Aug '99

24 Aug '99

4 5

Top 100 Maintainers List
by RIPE Database Manager 04 Aug '99

04 Aug '99

2 1