- db-wg - mailman.ripe.net

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

Re: Interesting object in the RIPE database
by Steven Bakker 11 Jul '99

11 Jul '99

>>>>> On Wed, 7 Jul 1999, "RLE" == Robert_Martin-Leg=E8ne wrote: RLE> Doesn't mean that it makes sense in the IP Registry world. Let's be RLE> practical. And besides, classful addressing is a Thing of the Past (ahem). The BSD way of doing it is clever, but complicated and it has no place in the DB, IMO. I always understood that the DB software would pad missing octets at the end of an IP address, no ambiguity there. What I'm surprised about is that the DB apparently allows someone to register address space that's most likely not even theirs... Of course, once it gets allocated and entered into the DB, a conflict will be detected and flagged (right!?), but until then, the error will go undetected. Is this a feature? Cheers, Steven

4 3

Interesting object in the RIPE database
by Niels Bakker 07 Jul '99

07 Jul '99

Hi, I noticed the following object in the RIPE database this afternoon: inetnum: 195.59.213.0 - 213.127.0.255 netname: WILLIAMBROOKES-TF13-GW descr: William Brookes School country: GB admin-c: PC2598-RIPE tech-c: IH22-ORG rev-srv: ns0.insnet.net rev-srv: ns1.insnet.net status: ASSIGNED PA mnt-by: AS5378-MNT changed: cliveg(a)insnet.net 19990706 source: RIPE (I stumbled over it while querying the RIPE database for an object within the APNIC database while accidentally omitting the -a option.) Clive Galway (the creator of this object) told me after I contacted him that he had entered the following information into the template: 195.59.213.0 - 213.127 instead of 195.59.213.0 - 195.59.213.127 He added, "funny that it dont complain though" - I agree wholeheartedly with him here. :) A check for the number of dots in the inetnum: line should be quite easy, and similar to this: # fix for people who don't include the first two or three octets s/^(\d+\.\d+)\.(\d+\.\d+) - (\d+\.\d+)$/$1.$2 - $1.$3/ s/^(\d+\.\d+\.\d+\).(\d+) - (\d+)$/$1.$2 - $1.$3/ if ($_ =~ /^\d+\.\d+\.\d+\.\d+ - \d+\.\d+\.\d+\.\d+$/) { &complain; } I believe there is a sub to check whether something is a valid IP address but can't find it offhand in my (by now pretty dated) copy of the RIPE database software... With regards, -- Niels Bakker, * * EuroNet Internet BV Network Operations * * Herengracht 208-214 * 1016 BS Amsterdam NJB9 * +31 (0)20 535 5555

3 2

Converting named references to NIC handle references
by Engin Gunduz 29 Jun '99

29 Jun '99

Dear collegues, As discussed and agreed to in the mailing lists, we will be converting unambiguous named references in the admin-c and tech-c fields of as-macro, autnum, community, dom-prefix, inet-rtr, mntner and role objects to NIC handle references, on 1 July, 1999, at 17:00, GMT. The process will take around half an hour, and during the process the updates will be queued. Whois queries will not be affected. The maintainers of the affected objects will get notifications about the changes. The conversion on domain and inetnum objects will be done at a later date, due to substantial time they require for this process. If you have any questions, please do not hesitate to contact us. Regards, Engin Gunduz RIPE NCC DB Group

1 0

T1
by OrderOffice - ICP Lueck und Lanzrath GbR 25 Jun '99

25 Jun '99

T1

1 0

address field limitation???
by Pedro Goncalves 25 Jun '99

25 Jun '99

Hi I would like to know what is the char limit (if any) for the address field. Some of my submitions apparently where returned because of the usage of more than 64 chars. Best regards Com os melhores cumprimentos. Pedro Gonçalves Telepac, SA Tel: 351-1-7907354 Fax: 351-1-7907001

2 1

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) 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 --------------------------------------------------------------------------

3 2

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

>I explicitly excluded those objects from this run. Great. >I knew this thing was going to be a bit polemic so I am trying to split into >smaller problems and stages that we can all agree to. Well, complex, at least. I fully support your approach! >Hopefully every step will reduce the number of objects that need repairs. And >believe me, it's not the same to have to fix 250000 objects than to fix 25000. >Somehow the latter seems a bit more feasible (from a "let's deal with this" >attitude). Certainly. >So, can we agree to proceed with our suggestion as stated below? >** >Change references by names to references by nic handle where these are unique >(there are not already more than two persons with the same referenced name). >** I agree. >For the cases where the ambiguity is already there: we'll look at them, try to >categorize them Sounds interesting. I really like the approach taken by Poul-Henning with his IP address page. Maybe we can come up with a similar list, e.g. categorized by object type, and within the object type by LIR, TLD, AS-#, Maintainer... >and maybe identify another subset which can be handled by >drawing information from some other source. >We'll get back to you with our suggestion (and we take the two you mention as >input). Any input is most welcome. Wilfried.

1 0

Re: Modifying references to contact info in the RIPE DB
by Janos Zsako 24 Jun '99

24 Jun '99

> From owner-db-wg(a)ripe.net Thu Jun 24 15:23:02 1999 > From: Joao Luis Silva Damas <joao(a)ripe.net> > ALMOST NONE except that: > from that point on if someone else with a name equal to one already in the > database is entered into the database the reference will not be made ambiguous > while if we leave it as a reference by name it sure becomes ambiguous. I agree with Joao that there is virtually nothing to lose. I don't think it is better to have a reference by name with a single incorrect instance of a person object with that name, rather than a NIC-handle reference to the same incorrect instance... (By incorrect instance I mean a person object with the same name, but who has nothing to do with the referring object). At the same time the benefit is obvious (see above). Also, the longer one delays this process, the better the chances to have several instances to be handled manually (i.e. to try to identify the correct person object from several ones with the same name). Just my 2 filler (.01 HUF). :)) Janos

1 0

Re: Modifying references to contact info in the RIPE DB
by Janos Zsako 24 Jun '99

24 Jun '99

> From owner-db-wg(a)ripe.net Thu Jun 24 14:35:25 1999 > From: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> > One of the key things might be to make sure that we (you :-) can perform > a roll-back, if it turns out that we've messed up things badly... My feeling is that if one replaces the name reference with the NIC-handle, at least as long as the referenced person object is not deleted (which I suppose cannot be deleted once it has an other object referencing it), the roll-back is always possible (i.e. one could re-substitute the NIC-handle with the name). Although, I feel this would be in the best case useless, since either there is no other person object with the same name, or the other object(s) was(were) added later. Janos

1 0

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

Hi Joao! >So, in spite of the concerns raised (valid as they are) I would still >vote to go ahead on this one as proposed. > >What do people think? Well, some as yet unstructured rants, off the top of my head... I'd love to see some sort of test-run being performed, e.g. going ahead and putting the result up as the (or an additional) test db? One of the key things might be to make sure that we (you :-) can perform a roll-back, if it turns out that we've messed up things badly... Is there any chance to do some sort of dry-run, and put up some sort of list of cases deserving investigation? Poul's page is a very good thing, indeed, although tackling a different aspect. My reasoning is that whatever can be fixed by humans, in a distributed project, before the brute-force attack would make life easier. Most probably basic rule #1 applies to my comments: use the brain before using the keyboard :-) 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 --------------------------------------------------------------------------

2 1

Modifying references to contact info in the RIPE DB
by Joao Luis Silva Damas 24 Jun '99

24 Jun '99

Dear all, the Database consistency project has been going forward in its goals since RIPE 33 (eg. addition of nic handles to all objects without one.) Statistics and reports about the "status" of the database can be seen at http://www.ripe.net/db/state/. We will keep adding information to these pages as the project progresses. We are now at the point where we would like to tackle the issue of references by name in the admin-c, tech-c and zone-c. As a next step, we would like to have references by nic handles (which are unique) instead of references by name (which can be non -unique). At this point, we would like to automatically go through all the references by name which can uniquely be assigned to a person or role object and substitute them by references to their nic handles. This will prevent these references from becoming non-unqiue in the future. Later we will go through the process of fixing the non-unique references left in the database. This process requires user intervention since we can't decide who "owns" a particular set of resources. For this later stage, we will be preparing reports that we will send to all maintainers for whom we detect objects with inconsistencies and try to get them fixed. Information about this part will be sent to the lists in a few weeks. We would like to do this after as much as possible has been done by automatic means to correct inconsistencies so that human effort is reduced to a minimum. If there are any concerns regarding this move, please make them known before next Friday (June 25th). Looking forward to your comments, Joao Damas Database Group RIPE NCC

4 6

Changing old format dates in the RIPE DB
by Joao Luis Silva Damas 24 Jun '99

24 Jun '99

Dear all, we are going to start with the procedure to modify all the dates in the changed fields of database objects that were using only two figures for the year. After the modifications, the year part of the date will contain 4 digits. Changed fields which currently do not have a date will not be changed (*) This is taking place according to the action points agreed on the Vienna RIPE meeting. The process will be carried over the next few days due to the time it takes to re-index some of the bigger files. Regards, Joao Damas DB Group RIPE NCC (*) These objects will not be updatable by the user unless a date is included at update time or the only changed field without a date is the last one, in which case the database automatically fills in the date at which the update takes place.

1 0

Update processing delayed
by RIPE Database Administration 22 Jun '99

22 Jun '99

Dear Colleagues, the database is very loaded now, due to some huge updates sent tonight. The queue of waiting updates is very long and you should be prepered for waiting times of several hours before your update gets processed. Please do not resend your updates. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Roman Karpiuk ____________________________ The RIPE NCC Database Group.

1 0

Adding nic handles to objects without one
by Joao Luis Silva Damas 16 Jun '99

16 Jun '99

Dear all, as discussed and agreed to during discussions in the mailing lists and at the RIPE Meeting in Vienna, the RIPE NCC will be adding newly generated NIC handles to person objects that do not currently have one. Over the last days we have been testing the procedures to do this in a non-disruptive way. Unfortunately, due to the nature of the current database, the process needs about 5 hours to run. Due to this and to avoid interactions with nightly jobs that create several copies of the files, including the ftp site and the full text search indexes, we will stop updates tomorrow Tuesday at 19:00 (Amsterdam time). This will cause all updates to the DB sent after 19:00 to be queued for later processing that night. There is no need to send updates more than once. Queries will not be affected. That is, the whois server will keep answering queries normally. During the process, objects without nic handles will get unique new ones and also a "changed" attribute will be added with tomorrow's data and ripe-dbm(a)ripe.net as the author of the change. This is for future reference. If you have any questions, please do not hesitate to contact us. Best regards, Joao Damas DB Group RIPE NCC

2 1

RE: status on RIPE-DB rewrite
by Wilfried Woeber, UniVie/ACOnet 07 Jun '99

07 Jun '99

Rick, >can anyone give a status on the ripe-db rewrite in 'C' http://www.ripe.net/meetings/ripe/ripe-33/pres/db-reimpl/index.html might provide you with some answers. I'm sure RIPE NCC staff can give more details, if required. 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 --------------------------------------------------------------------------

2 1

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