July 1998 - 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

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

New release of the RIPE DB in production
by Joao Luis Silva Damas 21 Jul '98

21 Jul '98

Dear all, as announced last week, yesterday we installed version 2.1.3 of the RIPE DB software in our production systems. This version has been available for download from our ftp site since July 15th. The main changes in changes in version 2.1.3 are: - Changed attributes are no longer shown by default in any query. If you want to see them you will have to use the -c option. The database doesn't look at the changed attributes in updates so if you don't want to loose them when updating objects, make sure you first get the object using the -c option and update that. - Inclusion of cross notification in the Routing registry. For details see the RELEASE NOTES included below, Regards, Joao RELEASE NOTES for RIPE Database 2.1 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi3.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES Changed attributes ------------------ This release modifies the default behaviour of the whois daemon by not displaying the "changed" attributes in any objects as result of a query unless specifically requested to do so, by using the new -c whois query option. Updates and deletes ignore the changed files so if an update differs from the previous object only in the changed fields a NOOP will be returned. Cross notification in the Routing Registry ------------------------------------------ A new major feature in this release is cross notification in the routing registry. Cross notification works according to: 1. Whenever a route object is added to the routing registry, a check is done to see if the address space overlaps with that in any other route object in the RR. If so, a notification will be sent to the submitter of the route object. This will always happen and is not dependent on any notification attributes described below. 2. Two new fields called "cross-nfy:" and "cross-mnt:" have been added to the route and aut-num objects. The "cross-nfy" field: a) contains a contact reference, specified as a NIC-handle pointing to a person or role object, the email address of which will get the notification; b) is optional; and c) is multiple (so that more than one contact can be notified). The "cross-mnt" field: a) contains a contact reference, specified as a mntner ID referencing the maintainer to be notified; b) is optional; and c) is multiple (so that more than one contact can be notified). This attribute is used to request notifications of the addition or removal of route objects which overlap the address space of the already registered route objects in which this attribute is specified. If the "cross-nfy:" or "cross-mnt:" attributes are used in: + a route object, then a notification will be sent for any overlaps with the address space specified in the route object; + an aut-num object, then a notification will be sent for overlaps with the address space specified in each route object in which the given AS number is specified in the "origin:" attribute. The contact/s in "cross-nfy:" or the mnt-nfy/s in the maintainers referenced by the "cross-mnt:" will receive an e-mail whenever: + a route is registered which overlaps this address space; or + a route is removed which overlapped this address space. If all is well, the former will indicate the introduction of multi-homing, and the latter will indicate the cancellation of the multi-homing. It is expected, however, that the former will often indicate an error, and the latter its removal. Either way, it will be useful to know about the registration and elimination of overlapping announcements. The set of sources searched for these conflicts is defined on a server wide basis (CROSSNOTIFYSOURCES in ripedb.conf). BUG FIXES Better check for disk full conditions when writing to the database Workaround for bug in perl handling integer numbers Performance improvements, better checks on forking and misc. additions contributed by users.

1 0

whois service problems
by RIPE Database Administration 17 Jul '98

17 Jul '98

Dear All, There was a problem with our whois service again this morning, Friday 17th of July between 4.30 and 9.30 a.m. The whois server was running but answers to all queries were empty. Please note, that updates were not affected by that. You do *not* need to resend your updates. The problem was caused by an error in scripts performing mirroring between the master data/update server and the whois server. This was corrected at 9.30 and fixes were implemented preventing (hopefully) this kind of problems from reoccurring. We wish to thank those of you who took the time and the trouble to notify us. We apologize for any inconvenience this might have caused. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Roman Karpiuk ____________________________ RIPE Database Administration.

1 0

RIPE NCC whois outage
by Joao Luis Silva Damas 16 Jul '98

16 Jul '98

Dear all, this afternoon at 18:00 the whois server was down for approx. 5 min. This was due to a crash of the machine caused by a kernel problem. The system is up again and the cause is being investigated. Regards, Joao Damas RIPE NCC

1 0

New release of the RIPE Database code
by Joao Luis Silva Damas 15 Jul '98

15 Jul '98

Dear all, a new release (2.1.3) of the RIPE Database code is available for download. If you detect any problems, please send a mail to ripe-dbm(a)ripe.net The release notes for this version are the end of this message. Regards, Joao Damas RIPE NCC ********** RELEASE NOTES for RIPE Database 2.1.3 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi3.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES Changed attributes ------------------ This release modifies the default behaviour of the whois daemon by not displaying the "changed" attributes in any objects as result of a query unless specifically requested to do so, by using the new -c whois query option. Updates and deletes ignore the changed files so if an update differs from the previous object only in the changed fields a NOOP will be returned. Cross notification in the Routing Registry ------------------------------------------ A new major feature in this release is cross notification in the routing registry. Cross notification works according to: 1. Whenever a route object is added to the routing registry, a check is done to see if the address space overlaps with that in any other route object in the RR. If so, a notification will be sent to the submitter of the route object. This will always happen and is not dependent on any notification attributes described below. 2. Two new fields called "cross-nfy:" and "cross-mnt:" have been added to the route and aut-num objects. The "cross-nfy" field: a) contains a contact reference, specified as a NIC-handle pointing to a person or role object, the email address of which will get the notification; b) is optional; and c) is multiple (so that more than one contact can be notified). The "cross-mnt" field: a) contains a contact reference, specified as a mntner ID referencing the maintainer to be notified; b) is optional; and c) is multiple (so that more than one contact can be notified). This attribute is used to request notifications of the addition or removal of route objects which overlap the address space of the already registered route objects in which this attribute is specified. If the "cross-nfy:" or "cross-mnt:" attributes are used in: + a route object, then a notification will be sent for any overlaps with the address space specified in the route object; + an aut-num object, then a notification will be sent for overlaps with the address space specified in each route object in which the given AS number is specified in the "origin:" attribute. The contact/s in "cross-nfy:" or the mnt-nfy/s in the maintainers referenced by the "cross-mnt:" will receive an e-mail whenever: + a route is registered which overlaps this address space; or + a route is removed which overlapped this address space. If all is well, the former will indicate the introduction of multi-homing, and the latter will indicate the cancellation of the multi-homing. It is expected, however, that the former will often indicate an error, and the latter its removal. Either way, it will be useful to know about the registration and elimination of overlapping announcements. The set of sources searched for these conflicts is defined on a server wide basis (CROSSNOTIFYSOURCES in ripedb.conf). BUG FIXES Better check for disk full conditions when writing to the database Workaround for bug in perl handling integer numbers Performance improvements, better checks on forking and misc. additions contributed by users.

1 1

status attribute of the inetnum object.
by RIPE Database Administration 09 Jul '98

09 Jul '98

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.

1 0

Problems with whois and auto-dbm.
by RIPE Database Administration 08 Jul '98

08 Jul '98

Dear Colleagues, Yesterday morning, there were problems with the whois service and with auto-dbm. Unfortunately, the RIPE NCC was closed yesterday for the annual staff day. The staff were out of the office, in a rural location. Thus, when we became aware of the problems, our response time was longer than usual. A message explaining the situation was posted, but again unfortunatley, this message does not appear to have been delivered. We have fixed the problems and wish to thank those of you who took the time and the trouble to notify us. Murphy's Law worked overtime yesterday, but thankfully, once we knew that there was a problem, it did not prevent a dash to the RIPE NCC office using various types of transport. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ________________________ RIPE NCC Database Group.

1 0