- db-wg - mailman.ripe.net

IRRd source code release
by Gerald Andrew Winters 18 Aug '98

18 Aug '98

For those who are interested we are announcing our first IRRd source code release which can be found at the following location: http://www.merit.edu/radb/irrd We will be updating the source code periodically with bug fixes, feature enhancements, etc... Each new IRRd release will be tagged with the version number to distinguish it from prior releases. The current code release is version 1.0. We wish to thank those people who have already begun to test IRRd and we continue to solicit users who feel they might be interested in the IRRd software package. -- IRRd Development Team <irrd-support(a)merit.edu>

1 0

"Changed:" field
by Andrey Petukhov 17 Aug '98

17 Aug '98

Dear Colleagues, I'd like to propose new behavior of the "Changed:" field of the database objects. It would be more convenient if database (or its front-end robot, processing requests from mail messages) sets value of the "changed:" field itself using "From:" field of the mail header/envelope. Database could contain "changed:" information in three modes depending of user needs: 1. Only one record, reflecting last change. 2. Two records, reflecting event of the creation of the object and "last changed" event. 3. Full history of the changes. The first record means "created", and next records reflect every change, sorted by date. The mode of the "Changed:" field can be described in the "mntner" object and is applied to all objects controlled by this mntner. The default behavior of this field applied to objects without mntner. In all cases the field(s) "changed:" have form "Changed: <e-address> <date>", as it is now, but <e-address> is retrieved from mail header/envelope with appropriate authorization checks (it is being done now), <date> is current date of the modification. There is no need to store changes itselves, that is subsequent versions of the object are not stored. Best Regards, -- Andrey Petukhov (AP9-RIPE) Phone: +7 095 705 9229 Systems Engineer Fax: +7 095 929 9363 Global One Russia (RoSprint) Mailto:pooh@ipnms.rosprint.net

1 0

Performance of the RIPE Database
by RIPE Database Administration 17 Aug '98

17 Aug '98

Dear Colleagues, There is normally a delay of 10 minutes between an update being processed and it being visible using the whois service. We are aware that this delay has increased and we are taking action now to maintain the delay at normal levels. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Performance of the RIPE Database.
by RIPE Database Administration 10 Aug '98

10 Aug '98

Dear Colleagues, There is a time-delay between when an object is processed by <auto-dbm(a)ripe.net> and when it is visible through the whois service. This delay is normally 10 minutes. This delay became very long recently, but no updates were lost. If you received an acknowledgement mail, which said that your update was successful, then your update was indeed successful. No updates were lost. The problem is fixed now. If you continue to have problems, please contact <ripe-dbm(a)ripe.net> with details of the problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Announce: IRRd-1.0 Beta Release
by Gerald Winters 07 Aug '98

07 Aug '98

IRRd-1.0 Beta Release --------------------- Merit Network is pleased to announce the 1.0 Beta release of the Internet Routing Registry Daemon (IRRd): http://www.merit.edu/radb/ IRRd is designed as a stand-alone routing registry server. IRRd handles RIPE-181 and RPSL whois and RAToolSet queries, as well as database management tasks, including mirroring and object submission. Future versions will support object authentication and notification. The IRRd server features a Cisco Systems-like management and configuration interface. The IRRd architecture was designed to address performance problems with the original RAWhoisd and RADB databases. The current IRRd version supports router configurations up to 600% faster than previously. The IRRd server also supports indexing to disk and memory, handles both the RIPE-181 and RPSL databases, determines database syntax dynamically, and indexes the entire IRR in about a minute. Although this is a beta release, the software is currently in production use as the main RABD (whois.ra.net) server. The current beta release only includes binaries. A complete source code release is planned at the end of the beta trial (anticipated mid September 1998). IRRd is freely available and may be redistributed so long as the University of Michigan copyright is preserved. Development of the RPSL portions of IRRd were supported by the National Science Foundation (NCR-9321060). All other sections were supported by Merit Network, Inc. The ongoing IRRd efforts include significant efforts by a number of Beta testers, including Kevin Oberman (ESnet), Mark Prior (connect.com.au pty ltd), John Heasley (Verio), George Matey (Bay Networks), WeeSan Lee (USC/ISI), and Pierre Thibaudeau (Teleglobe). Many thanks for your suggestions and support! A mailing list, irrd-discuss(a)merit.edu, has been created for IRRd users to share experiences and advice. Subscribe by sending mail to irrd-discuss-request(a)merit.edu. -- IRRd Development Team <irrd-support(a)merit.edu> Gerald Winters Craig Labovitz Tom Spindler Jake Khuon Susan R. Harris

1 0

SUCCEEDED: Person: Wilfried Hauf (fwd)
by Hostmaster Schlund+Partner GmbH & Co. 07 Aug '98

07 Aug '98

Hello Hostmaster, as you can see, this Handle has been created at 8:32 today, which is 10:32 local time. Now, THREE hours after, ...: admin hostmast ~%date; wripe WH724-RIPE Fri Aug 7 13:23:43 CEST 1998 [sequoia.ripe.net] % Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html % No entries found for the selected source(s). % % If you would like to search on arbitrary strings, % please see the Database page on the RIPE NCC % web-site at http://www.ripe.net/db/ % This will only work for RIPE data. This is not a single case, all our handles aren't available hours(!) after the succeeded mail has arrived. The 10 Minutes stated in the return messages would be okay, but we can't afford to have one day between handle registration and domain registration. I consider this a serious problem. Can you tell me if this is going to be fixed soon? Kind regards, Eric Schaetzlein Schlund + Partner GmbH & Co. Erbprinzenstr. 1 Tel. +49-721-91374-50 76133 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de hostmaster(a)schlund.de ----- Forwarded message from RIPE Database Management <ripe-dbm(a)ripe.net> ----- Date: 7 Aug 1998 08:32:13 -0000 To: hostmaster(a)schlund.de From: RIPE Database Management <ripe-dbm(a)ripe.net> Subject: SUCCEEDED: Person: Wilfried Hauf Reply-To: ripe-dbm(a)ripe.net Your update was SUCCESSFUL, but it can take 10 minutes before your update is visible using a whois look-up. > From: hostmaster(a)schlund.de > Subject: Person: Wilfried Hauf > Date: Fri, 7 Aug 1998 10:19:22 +0200 > Msg-Id: <E0z4hkA-00040w-00(a)admin.schlund.de> The following objects were processed. New OK: [person] WH724-RIPE (Wilfried Hauf) ----- End forwarded message -----

1 0

Re: status attribute of the inetnum object.
by Paula Caslav 29 Jul '98

29 Jul '98

Dear Hank & colleagues, Hank Nussbacher <HANK(a)VM.TAU.AC.IL> writes: * On Thu, 09 Jul 1998 21:19:18 +0200 you said: * > * >Dear Colleagues, * > * >We intend to make the status attribute of the inetnum * >object mandatory on Monday, 13th July next. This has * >been discussed and agreed previously. However, if you * >have software that is _unavoidably_ dependent on this * >attribute being optional, please contact us. * > * >The new version of the inetnum object will be: * > * > * >inetnum: [mandatory] [single] [primary/look-up key] * >netname: [mandatory] [single] [look-up key] * >descr: [mandatory] [multiple] [ ] * >country: [mandatory] [multiple] [ ] * >admin-c: [mandatory] [multiple] [inverse key] * >tech-c: [mandatory] [multiple] [inverse key] * >rev-srv: [optional] [multiple] [ ] * >status: [mandatory] [single] [ ] # mandatory !!! * >remarks: [optional] [multiple] [ ] * >notify: [optional] [multiple] [inverse key] * >mnt-by: [optional] [multiple] [inverse key] * >mnt-lower: [optional] [multiple] [ ] * >changed: [mandatory] [multiple] [ ] * >source: [mandatory] [single] [ ] * > * >If you have anymore questions, please contact * ><ripe-dbm(a)ripe.net>. * > * >Regards, * > * >Ambrose Magee * >____________________________ * >RIPE Database Administration. * > * > * * I think the RIPE documentation needs some updating. * * ----------------------------------------------- * The status field can have one of these values: * * ALLOCATED PA (the most common allocation type for Local IR's) * * ALLOCATED PI (rare for Local IR's) * * ALLOCATED UNSPECIFIED * * ASSIGNED PA * * ASSIGNED PI * * These five values are explained in ripe-140. * ------------------------------------------------- * There is no ripe-140. Yes, you're right that needs to be updated. This quote comes from the database document ripe-157 and the document should actually point to ripe-159, we'll change that with the next version of ripe-157. We're also changing the output of "whois -t inetnum" right now to mention ripe-159. * Next. * * >From ripe-142: * ---------------------------------------------------- * status: Specifies whether the request is provider * aggregatable or provider independent. * Should be filled in with either "ASSIGNED * PA" or "ASSIGNED PI". * ---------------------------------------------------- * * No mention of "allocated PA" or "allocated PI" or * "allocated unspecified". The reason why we don't mention the various "allocated" attributes in ripe-142 is because only the RIPE NCC makes allocations, registries should only be entering "assignments" into the database, and therefore should always put "ASSIGNED" in the status attribute on the ripe-141 form which this document describes. In ripe-159, the general policy and procedures document, however, all types of allocation and assignment status types are described. (section 3.4.2 for assignments and section 4.4 for allocations) * I think the RIPE documents need to be updated. There should be * a pointer to ripe-127 instead. Good idea! It's added to the to-do list. :-) Kind regards, Paula Caslav Registration Services Manager RIPE NCC * -Hank * *

1 0

Re: status attribute of the inetnum object.
by Hank Nussbacher 28 Jul '98

28 Jul '98

On Thu, 09 Jul 1998 21:19:18 +0200 you said: > >Dear Colleagues, > >We intend to make the status attribute of the inetnum >object mandatory on Monday, 13th July next. This has >been discussed and agreed previously. However, if you >have software that is _unavoidably_ dependent on this >attribute being optional, please contact us. > >The new version of the inetnum object will be: > > >inetnum: [mandatory] [single] [primary/look-up key] >netname: [mandatory] [single] [look-up key] >descr: [mandatory] [multiple] [ ] >country: [mandatory] [multiple] [ ] >admin-c: [mandatory] [multiple] [inverse key] >tech-c: [mandatory] [multiple] [inverse key] >rev-srv: [optional] [multiple] [ ] >status: [mandatory] [single] [ ] # mandatory !!! >remarks: [optional] [multiple] [ ] >notify: [optional] [multiple] [inverse key] >mnt-by: [optional] [multiple] [inverse key] >mnt-lower: [optional] [multiple] [ ] >changed: [mandatory] [multiple] [ ] >source: [mandatory] [single] [ ] > >If you have anymore questions, please contact ><ripe-dbm(a)ripe.net>. > >Regards, > >Ambrose Magee >____________________________ >RIPE Database Administration. > > I think the RIPE documentation needs some updating. ----------------------------------------------- The status field can have one of these values: ALLOCATED PA (the most common allocation type for Local IR's) ALLOCATED PI (rare for Local IR's) ALLOCATED UNSPECIFIED ASSIGNED PA ASSIGNED PI These five values are explained in ripe-140. ------------------------------------------------- There is no ripe-140. Next. >From ripe-142: ---------------------------------------------------- status: Specifies whether the request is provider aggregatable or provider independent. Should be filled in with either "ASSIGNED PA" or "ASSIGNED PI". ---------------------------------------------------- No mention of "allocated PA" or "allocated PI" or "allocated unspecified". I think the RIPE documents need to be updated. There should be a pointer to ripe-127 instead. -Hank

1 0

What happened to RIPE Database full text search?
by ludger.bornhorst＠t-online.de 23 Jul '98

23 Jul '98

Dear all, since a short time I get the following answer on any query in http://www.ripe.net/cgi-bin/ripedbsearch: >The following problem occured during the search: > > No objects were found matching the search criteria > > Please try again! Maybe this error arose since the new RIPE-db version 2.1.3 has been implemented last Monday? -- Ludger Bornhorst, Deutsche Telekom AG, ZDK Zentrum fuer Datenkommunikation, Oldenburg, Germany Tel.: +49 441/234-5678 Fax : +49 441/27463

5 5

Re: What happened to RIPE Database full text search?
by Christian Panigl, ACOnet/UniVie 22 Jul '98

22 Jul '98

>Date: Wed, 22 Jul 1998 13:03:24 +0200 >From: Joao Luis Silva Damas <joao(a)ripe.net> > >Nothing happens to the RIPE DB itself. > >However, the full search text is not working at this moment. >We are investigating and working on fixing it. Hi Joao, not only full text search doesn't work but also ftp.ripe.net/ripe/dbase/split/* files are empty !!! Is this a related problem ? Are you already working on that ? Besides other things we are building our actual routing-filters based on those split-files ! Kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1