July 1996 - db-wg - mailman.ripe.net

FYI: new database code in production
by David.Kessens＠ripe.net 31 Jul '96

31 Jul '96

Dear all, Hereby, I want to announce that we have put the new RIPE database release 2.00 in production. Since this version is a major upgrade, we certainly expect a few problems (unfortunately we already found some and fixed them already ;-)). Please take a close look at your updates and send me (<ripe-dbm(a)ripe.net> only) your bug reports so that I can fix any possible problems. I am still finalizing the documentation (with more detailed information on the new features) and the software distribution package. You can expect a separate announcement from me on this later this week. And finally: I want to apologize for the late announcement of this upgrade and the confusion that might have been caused by this. If you have any further questions, please don't hesitate to contact me, Kind regards, David K. ----- *****Preliminary release notes*****: Dear all, This message is to announce the new 2.00 release version of the RIPE database. Many new features and bug fixes have been added since the the previous beta release. The following lists the most interesting new features since the previous non-beta release: - AUTO NIC handle assignment support - hierarchical authorization for creation of 'inetnum' and 'domain' objects. - role object support - prefix notation for 'inetnum:' updates is supported and IP range notation for whois lookups - extended 'country:' attribute syntax implemented, more then one coutry on a line and more 'country:' attributes per object are allowed now. - the special RIPE whois client is now fully supported and included in the distribution. - much stronger syntax checking (=as strong as specified by the original database specification) for NIC handles, phone numbers, E-mail addresses, domain names (Some people might not like this ;-)). - network updates, a method for directly updating objects by use of the program 'networkupdate'. The use of this method is restricted by an accesslist and intended for the maintenance people of the database. - BSD DB dbm package is fully supported. This dbm package is a fast, platform independant and reliable dbm package. - No limitations on the number of hits (no matter what indexing package you use): a query like 'David' will give you an answer and person names like 'John George' will be found - new and more intelligent indexing program 'indexdb' that can do a raw index or a clean index and automatically detects if it is dealing with a classless index. netdbm & cleandb are now obsoleted. - reverse lookup of objects (whois -i option), this enables you to find for example the routes with a given origin as by doing: whois -h whois.ripe.net -i origin AS3333 - Nearly real time mirroring of the RIPE database. This feature is fully supported but has a few shortcomings that will involve a bit more administration work until the 'stored/processed' attribute and better crash recovery routines are implemented. - experimental inet6num support for ipv6 network objects, including support for -L, -m, -M queries. and many more small changes and fixes. Please read the release notes at the bottom of this message for more information and discussion about these topics. Please send bug reports/fixes directly to <ripe-dbm(a)ripe.net> and I will fix the problem but be fast since I will move to another job at ISI in August! Thanks for all your help, Kind regards, David Kessens RIPE NCC software maintainer ------- RELEASE NOTES (RIPE database version 2.00): - Nearly real time mirroring support: What is it: The database software now keeps serial numbers of all updates. If you have been added to an accesslist, it it possible to retrieve all the changes to the database. A program 'syncdb' has been added to the distribution that can retrieve these changes and update your mirror database automatically. This program is intended to be put in a cronjob. The whois erver has an access list so you first need to ask the site to be mirrored to add your host to the access list. Please let me now at <ripe-dbm(a)ripe.net> if you are interested in trying out this feature, and I will add the IP number of your site to the access list. Short discussion: Note that this is the first version, it currently uses seperate files internally for every update. We plan to change this since this is not really what we want with 2000 (atomic) updates on some days. Furthermore, we use currently an ever increasing integer serial number. A proposal (stored/processed attribute) on how to this right has already been circulated to the RIPE database working group and discussed on the RIPE meeting. Implementation of this attribute will also allow for a better crash recovery behavior. - No limitations on the number of hits (no matter what indexing package you use): a query like 'David' will give you an answer and person names like 'John George' will be found - New and more intelligent indexing program 'indexdb' that can do a raw index or a clean index and automatically detects if it is dealing with a classless index (from the config file). netdbm & cleandb are now obsoleted. The indexing speed has also been improved. - BSD berkeley DB support: The database software can now use the Berkeley DB dbm package. According to many people this package is superior to most other dbm packages that perl can use (unlimited size of keys/values, platform independent db files). We have put the current sources for this package at ftp://ftp.ripe.net/tools/db.1.85.tar.gz It should be possible with the BSD DB package to increase the OVERFLOWSIZE and as result get rid of (most) of the overflow files. However, it is not clear if this is desirable since it doesn't seem to make the software more memory/space/speed efficient. - a new help and HOWTO use the RIPE database file is available use 'whois -h whois.ripe.net HELP' to get the most recent version. The document gives a short introduction on the database, tells you how to create/update/delete objects, contains a section with tips and common problems and gives pointers to other documentation about the database. - BSDI/perl memory leak problems Due to a memory leak with perl on BSDI machines we needed to make the code more memory conscious. enread.pl has been rewritten completely and uses now less memory and as an (intended) side effect became faster when reading big objects. Also the special input routine for reading in an object from an E-mail has undergone the same optimizations. - Most patches (for greater speed and less memory consumption) that I received from Curtis Villamizar <curtis(a)ans.net> have been included. Thanks Curtis! - The direct network updating method is now fully supported. Currently this method is only intended for use by the registry itself, however it is possible to add support in the maintainer objects if desired by the RIPE community. You can now do you updates very rapidly by giving the command 'networkupdate' and input your object via STDIN. Of course, this is also protected with an access list. - The special magic to overrule the maintainer protection needs a password now. Syntax will be published after the main registries support this... - All support for the historical 'guarded' objects have been removed. The guardian attribute can be obsoleted if the database working group wishes to. Present guardian attributes will act as a 'notify:' attribute. - the special RIPE whois version is now fully supported and included in the distribution. - cryptpw is a new (small) program that encrypts a password with a shoosen salt for use in the maintainer objects. - dbupdate -T Makes it very easy to install your own test database. The only difference with a normal update is that it doesn't need manual authorization for creation of maintainer objects and that it will add a warning to your acknowlegment message that this is not the normal behavior... - status: attribute as described in ripe-127 fully supported - whoisd changes: -D runs in daemon mode otherwise in 'inetd' mode ('inetd' mode is untested) The number of disk accesses have been further minimized and should result in a better performance. - line continuation by use of a "\" character at the end of an attribute line in your update message. The database software will then automatically concatenate the next line with the previous one. - prefix notation for 'inetnum:' updates and IP range notation for whois lookups is supported - extended 'country:' attribute syntax implemented. You can now specify multiple countries in a 'country:' attribute line. - much stronger syntax checking for NIC handles, phone numbers, E-mail addresses, domain names (Some people might not like this ;-)). The syntax was too relaxed and follows our own specifications more closely. - perl5 patches. perl5 is still not supported. However, the biggest problems should be gone now (the software runs with perl5 at home with Linux & perl5.001m). The Makefiles have been changed to support perl5 and some of the database tools as 'whois' can be configured to run with perl5 by default (and work with it!). See the Makefiles on how to configure this. You are welcome to experiment with perl5 and we are interested in your comments! - Tony Bates <Tony.Bates(a)mci.net> recent patch for a problem with the maintainer notifications. Thank you Tony. - databases and serial number files that don't exist are now autogenerated. - Config file has been simplified by removing some options that can be determined by the database software itself. Of course, also a few new options appeared. Everything is documented in the config file itself. - The Makefiles have been rewritten to allow for easier installation and more logical behavior when doing make [[un]install]. - many small fixes and clean up of the code to make above changes possible. - bug that caused problems when deleting objects with(out) syntactic sugar - bug that caused a crash when one tries to delete an object that cannot be updated (object is mirrored from other database) - List of OS's that we know the RIPE database works with: - SUNOS - BSDI - Linux (Please inform me with you own results so that I can update this list!) Automatic on the fly patches implemented in the new Makefiles should make it possible to run the database on Solaris. This is untested for now and you will need a special perl4 that will be made available from ftp://ftp.ripe.net/tools. Peter Haag has made the perl version and patches available to me. Thanks! - The auto nic handle generation support (Gabor Kiss helped me with some patches) - Role object What didn't make it in this release: - checking for relations between objects: - disallow deletion of referenced object - disallow creation of objects that reference non exiting objects

1 0

Re: another lookup problem
by Wilfried Woeber, UniVie/ACOnet 24 Jul '96

24 Jul '96

=> What's the *inherent technology* difference between a registration => lookup and a general white pages service? = =Registration lookup deals with hierarchical namespaces, thus enabling =delegation of authority. True for (part of the) IP-Addresses and certainly for Domains. Not true for (at least) AS numbers and communities (and inet-rtr). I think the RIPE registry and DB-SW has never made an (explicit or implicit) assumption about a hierarchical structure of regsitry data. This was (for the address space and routing) introduced by the Class-C-Blocks, CIDR and Reg/Local-Registries approach, and the rwhois. > A general whitepages service deals with flat >namespaces which are much uglier to deal with, particularly as the >database scales. > >In addition, registration lookups (should) result in a boolean result, >it is either there or it isn't. A general whitepages service can >result in multiple hits, requiring additional resolution. Agreed. [....] => Then I don't understand why we have the recursive lookup for person => objects... = =Because person objects are indexed (or did I misunderstand the =question)? Partly, I think. I understood your reasoning to eventually propose removal of the person lookup as contacts for the (hierarchical) objects. Or to include the contacts directly with the objects? Otherwise, if you want to keep that functionality to find out about contacts, how would you do it without indexing? I seem to be missing something, maybe an implementation fact... Or have you been thinking about the *reverse* lookup? => Those of us who have to work with end-users have to process a lot of => requests that involve dealing with person objects. Whether they are => directly indexed or just referenced doesn't make a big difference. = =I understand. As I'm not a complete fanatic (:-)), I wouldn't throw =out the person name indexing without providing a replacement that =would allow people to lookup their names (I've been playing around =with LDAP -- seems OK, particularly given some browsers are now =appearing with LDAP clients). In the white pages record would be an =(optional) entry for NIC handle(s). So what's your proposal? To eventually run a whitepages server alongside the other software and to gradually move the person information to that other server and implement the linking by way of the handles? Or to rely on a whitepages service provided by third parties? => I want to find out whether some guy or gal is already in the DB - full => stop. And it's more comfortable to do that with a wildcard replacing a => "sharp s" or an umlau than being "radical" and try all the different => possibilities that I can imageine. = =This is a hard problem. My concern is that if you throw in stuff that =would allow fuzzy searches, you'll end up making the code more =complex, slower, and the resulting index files will likely get (much) =bigger. As I said at the beginning of this thread, introducing this functionality would need some major discussion and decision. Whether it would make the code more complex and slower and increase the size of the index files is then a question of implementation. > An alternative solution, already proposed by David (:-)) >would be to mirror the appropriate database files and use grep (or >more reasonably, given the requirements, glimpse or agrep). While >somewhat lacking in elegance, it'd probably be faster (given network >latency). Well, I never insist on a *specific* implementation, you know :-) And yes, that approach is already available. Even with the opportunity for setting up a "realtime" mirror DB. Whether we expect all the registry staff to use that approach is a different issue... But as long as nobody else speaks up, I think it's not a real issue, anyway. Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Re: another lookup problem
by Wilfried Woeber, UniVie/ACOnet 24 Jul '96

24 Jul '96

=> To what end? Is the purpose of the database registration information => lookup or a more general white pages service? I' would suggest the => former and leave the latter to the WHOIS++/LDAP/X.500 crowd. = =In general, I agree with this principle: = =The whois servers should be fast & reliable. Yes, it should be fast for simple queries. %server running in background has been introduced already reliability is not (directly) related to speed > We should only support >queries that the users (eg.: networking communitity) needs. Yes. >We better >don't support lookup methods that are more usefull for the 'sales & >marketing' department. However, this doesn't mean that we shouldn't be >user-friendly. Exactly. And when it's too difficult for the lawyers, they pay some nerd to help them them. Provides them with the data, the nerd with the money and us with the additional effort... Wilfried.

1 0

Re: another lookup problem
by Wilfried Woeber, UniVie/ACOnet 24 Jul '96

24 Jul '96

Hi David(s) ! =>=To what end? Is the purpose of the database registration information =>=lookup or a more general white pages service? I' would suggest the =>=former and leave the latter to the WHOIS++/LDAP/X.500 crowd. What's the *inherent technology* difference between a registration lookup and a general white pages service? Sure, ultimately the number of entries... As soon as we have a production environment with these tools (both from technology, software, coverage, logistics and web access) I'll be happy to move ;-) ==> ==> - local langauge problems (European National Character Sets) which make ==> it difficult to find out about a (arbitrarily chosen) transcription. = =Local language problems? Heh. Let me introduce you to traditional =Chinese with all 100,000+ characters :-). Thank you. For the time being I just (have to) appreciate them as a piece of art. Unfortunately I lack the time to dive into that to the degree I would like to master. But if there is any special consideration of transcribing these letters (well, more local language independent symbols?) into 7bit ASCII for a DB I'd be happy to be clued in. What I was primarily referring to is the 7bit transcription of European local languages for "funny" characters. While I don't know about other countries, e.g. I'm perfectly aware that even *within the German region*, there is differences in defined transcriptions: AT (and DE?) a "sharp s" is formally written as "sz" but usually we use the "ss" form in everyday transactions. CH the same is written as "ss" For Scandinavia there is a couple of different umlauts with double dots, crossing an "o" or ligatures, etc. Do you reaaly know about the transcription? => The advantage of the whois =>database serving as a simple registered object lookup mechanism is =>that you don't have to worry (too much) about gunk like local language =>support -- the registration database access method (whois) allows =>lookups on registry objects, namely inetnums, handles, domains, route =>objects, etc. of which people (generally :-)) are not a part. Then I don't understand why we have the recursive lookup for person objects... =Yes, I'm arguing person: field contents should not be indexed, but =I've been known as a radical in the past. Note this would have =solved the problem that brought this issue up (I think). Well, reality differs. Those of us who have to work with end-users have to process a lot of requests that involve dealing with person objects. Whether they are directly indexed or just referenced doesn't make a big difference. I want to find out whether some guy or gal is already in the DB - full stop. And it's more comfortable to do that with a wildcard replacing a "sharp s" or an umlau than being "radical" and try all the different possibilities that I can imageine. => - comments from other environments, where the lack of this feature was => quoted as a major obstacle to use this software 'cause this => functionality is provided right now. = =If all you have is a hammer, everything begins to look like a nail. =This doesn't mean you should attach a blender to your hammer to allow =making more consistent puree... Thank you :-) I just wonder why you need a blender when you've got a hammer? Just kidding :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

Re: another lookup problem
by Wilfried Woeber, UniVie/ACOnet 19 Jul '96

19 Jul '96

Hi David! => WRT "fuzzy" / wildcard matches - it would make the RIPE-DB software => more user friendly (and maybe more attractive for deployment by other => registries) to provide for (implicit/explicit) regexp or partial key => matches. = =To what end? Is the purpose of the database registration information =lookup or a more general white pages service? I' would suggest the =former and leave the latter to the WHOIS++/LDAP/X.500 crowd. Two things here: - local langauge problems (European National Character Sets) which make it difficult to find out about a (arbitrarily chosen) transcription. - comments from other environments, where the lack of this feature was quoted as a major obstacle to use this software 'cause this functionality is provided right now. The remark about the white pages is understood, although I don't think we should limit the sw functionality to avoid misuse :-) Thanks for throwing in your 2 yen. Wilfried.

4 3

Re: another lookup problem
by Gabor Kiss 19 Jul '96

19 Jul '96

> As to the 'illegal name' issue, I wonder if there are places where > the correct spelling of names allows a dot in the first word or the > last word (middle words are OK). This would allow cases like: Yes, Hungarian names may contain abbreviations as part of family name too. For example Kovacs F. Peter. The regular order of Hungarian names is: family name first, given name last. But we put them into RIPE database in English order, so "Peter Kovacs F" may occur. I've just found a real one: person: Jozsef Peresztegi N address: Walton Networking Kft. address: Almassy ter 2. address: H-1077 Budapest address: Hungary phone: +36 1 2679010 phone: +36 1 2679006 phone: +36 1 2679007 fax-no: +36 1 2679011 e-mail: J.Peresztegi.N(a)walton.hu nic-hdl: JPN1-RIPE changed: horvath(a)sztaki.hu 940330 changed: horvath(a)sztaki.hu 950816 source: RIPE > David R. Conrad > but blocks cases like: > Prof. Jones > U. Schultz > This check isn't perfect, but is reasonable because it catches most > common mistakes, and the ones that are left are harmless. Gabor

1 0

Re: another lookup problem
by Gabor Kiss 19 Jul '96

19 Jul '96

> 3. In some areas of the world (India?), people *really* have only one name. > Making the database resistent against these names doesn't help: > I see no reason to lock them out from using other registries > then the APNIC 'names fix' version. > > Rather than locking out people from India, I believe that the correct > approach is to enforce people to use NIC handles. We have been migrating > to that for quite some time, and maybe now is the time to cut over. One named persons might use a well known word as second name. Just like 'Singh' (Lion) at sikh people in India. ;-) Gabor

1 0

Re: another lookup problem
by Wilfried Woeber, UniVie/ACOnet 19 Jul '96

19 Jul '96

Hi David & DB folks ! >What happened: > >The software first searches for 'U. Schaefer' and cannot find anything. >Then it breaks up the 'U. Schaefer' in the following fields: > >U (trailing dots are discarded) >Schaefer > >the U key is discarded because it is too small (for a good reason) As much as I remember, this is in line with a recommendation from the DB-WG. >... >Short discussion: > >- U. Schaefer > > Names likes this will be rejected in the next release of the updating > code. Names should consist of at least two parts, not counting > abbreviated parts/titles. Good stuff. But I think we should try to weed out offending things before (or in parallel) with the introduction of this more stringent checks. I think we add just another level of complexity and user confusion if we don't... >- The inetnum object is incorrect: It references a non-existing person > object. This will not happen in normal circumstances. The new (not yet > deployed) updating code will disallow (most) non-existing references. Hmmm.... What about allowing an update but issuing a warning? And the other way 'round - issue a warning if an object which is still referenced gets removed. I'm not sure whether it makes sense to *sometimes* enforce link sanity and to allow for breaking them later (e.g. with a delete for the referenced object). Maybe that's just some aspects for a (hypothetical) package of sanity checks that might be activated regularly or upon request. >- the software should have found 'U. Schaefer' if the object existed (and > nothing more, see algoritm above) > >- I can change the indexing in such a way that that trailing dots are > indexed. However, this might be worse then the problem: accidental dots > after names cause the generation of different keys from the objects > where the dots are left out and thus objects that are obvious the same > are not seen as such anymore (by the software). I don;t think that we should make software chages to accomodate syntax errors. In a lot of different documents, the syntax for a person object is cleraly defined: name [initials] name - the initials to be registered without a trailing dot. At the same time titles and gender specific local language "syntactic sugar" is not allowed. Not sure whether there's a chance to guard against the proliferation of "Herr", "Frau", "Professor" etc... ~~~~~~ WRT "fuzzy" / wildcard matches - it would make the RIPE-DB software more user friendly (and maybe more attractive for deployment by other registries) to provide for (implicit/explicit) regexp or partial key matches. But I think that would be a major (conceptual) change and should be discussed, both technically and the human resources involved. Even if it might be easy to implement :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

4 5

another lookup problem
by Schmitz＠rus.uni-stuttgart.de 18 Jul '96

18 Jul '96

Dear David, just detected another problem with lookups: I do whois -h whois.ripe.net 192.108.55.0 and get a quite lengthy result - it finds far more persons than I expect. It is perfectly ok that it finds two "Klaus Friedrich" (obviously, there are two entries in the RIPE database). However, I am somehow confused where the program takes all these "Schaefer" from... Could you please check? Regards Joachim jade$ whois -h whois.ripe.net 192.108.55.0 route: 192.108.52.0/22 descr: DFN-AGG-23 origin: AS1275 advisory: AS690 1:1800 2:1128 3:293(147) 4:293(144) mnt-by: DFN-MNT changed: poldi(a)dfn.de 950907 source: RIPE inetnum: 192.108.55.0 netname: TELEKOM-DA1 descr: Deutsche Bundespost Telecom descr: D-W-6100 Darmstadt country: DE admin-c: F. Robens tech-c: Klaus Friedrich tech-c: U. Schaefer changed: poldi(a)DFN.DE 920714 changed: rv(a)Informatik.Uni-Dortmund.DE 920924 changed: ripe-dbm(a)ripe.net 920925 source: RIPE person: F. Robens address: Deutsche Bundespost Telecom address: Fernmeldeamt Dienststelle DE address: Grafenstrasse 10 address: D-W-6100 Darmstadt address: Germany phone: +49 228 181 4315 changed: poldi(a)DFN.DE 920714 changed: rv(a)Informatik.Uni-Dortmund.DE 920924 changed: ripe-dbm(a)ripe.net 920925 source: RIPE person: Klaus Friedrich address: Deutsche Bundespost Telekom address: Fernmeldeamt Dienststelle DE address: Grafenstrasse 10 address: D-W-6100 Darmstadt address: Germany phone: +49 6151 309 5741 nic-hdl: KF changed: poldi(a)DFN.DE 920714 source: RIPE person: Klaus Friedrich address: Dorfstr. 5a address: D-83646 Wackersberg address: Germany phone: +49 8041 77066 fax-no: +49 8041 77065 changed: ip(a)Germany.EU.net 950508 source: RIPE person: Schaefer address: RWW Rheinisch-Westfaelische Wasserwerksgesellschaft mbH address: Am Schloss Broich 1-3 address: D-W-4330 Muelheim an der Ruhr 1 address: Germany phone: +49 208 4433 336 changed: ar(a)deins.Informatik.Uni-Dortmund.DE 910919 changed: dfk(a)cwi.nl 910921 changed: rv(a)Informatik.Uni-Dortmund.DE 920508 changed: ar(a)deins.Informatik.Uni-Dortmund.DE 920511 changed: ripe-dbm(a)ripe.net 920513 source: RIPE person: Frank Schaefer address: Utescheny GmbH address: Gewerbestrasse 9 address: D-W-7519 Zaisenhausen phone: +49 7258 9101 13 fax-no: +49 7258 9101 17 changed: cp(a)deins.Informatik.Uni-Dortmund.DE 930526 source: RIPE person: Helmut Schaefer address: InterCom address: Broedele Strasse 2 address: Postfach 1525 address: D-W-7240 Horb 1 address: Germany phone: +49 7483 500 fax-no: +49 7483 1690 changed: cp(a)deins.Informatik.Uni-Dortmund.DE 930103 source: RIPE person: Herr Schaefer address: Didier Werke AG address: Abt. ZIT address: Postfach 2025 address: 65010 Wiesbaden address: Germany phone: +49 611 359-309 fax-no: +49 611 359-635 changed: ip(a)Germany.EU.net 931202 source: RIPE person: Mathias Schaefer address: C+L Unternehmensberatung GmbH address: New York Ring 13 address: D-22297 Hamburg address: Germany phone: +49 40 6378-2272 fax-no: +49 40 6378-1022 changed: ip(a)Germany.EU.net 940421 source: RIPE person: Brigitte Schaefer address: eXplico Software GmbH address: Peter-Henlein-Str. 9 address: D-81549 Muenchen address: Germany phone: +49 89 6892645 fax-no: +49 89 6892605 changed: ip(a)Germany.EU.net 940519 source: RIPE person: Lutz Schaefer address: Max-Planck-Institut fur Chemie; Abt. Luftchemie address: Saarstr. 23 address: Postfach 3060 address: D-55020 Mainz address: Germany phone: +49 6131 305 456 e-mail: LUS(a)ibma.IPP-Garching.MPG.DE nic-hdl: LS228 remarks: surname has typo in DDN-NIC whois changed: rv(a)Informatik.Uni-Dortmund.DE 920503 changed: rv(a)Informatik.Uni-Dortmund.DE 940812 source: RIPE person: Ralf Schaefer address: PRISMA Systemtechnik GmbH address: Zettachring 6 address: D-70567 Stuttgart address: Germany phone: +49 711 900092-00 fax-no: +49 711 90092-19 nic-hdl: RS4-RIPE mnt-by: DENIC-P changed: knocke(a)nic.de 941108 source: RIPE person: L. Bernd Schaefer address: Duropack Ges.m.b.H. address: Forsterstrasse 54 address: A-8401 Kalsdorf bei Graz phone: +43 1 8660 225 fax-no: +43 1 8660 316 nic-hdl: BS1-RIPE changed: <waltraud(a)eunet.co.at> 940323 changed: knocke(a)nic.de 941115 source: RIPE person: L. Bernd Schaefer address: Bupak address: JIP - Ceskobudejovicke papirny, a.s. address: Papirenska 41 address: Ceske Budejovice address: 370 52 address: The Czech Republic phone: +43 1 8660 225 fax-no: +43 1 8660 316 changed: ors(a)Czechia.EU.net 940223 source: RIPE person: Detlev Schaefer address: SMALLWORLD Systems GmbH address: Europaring 60 address: D-40878 Ratingen address: Germany phone: +49 2102 9195 32 fax-no: +49 2102 9195 11 e-mail: netadm(a)SWS-Ratingen.DE nic-hdl: DS5-RIPE mnt-by: DENIC-P changed: afs(a)Germany.EU.net 930625 changed: rv(a)Informatik.Uni-Dortmund.DE 930824 changed: knocke(a)nic.de 941121 source: RIPE person: Ralf Schaefer address: Comtec GmbH address: Max-Stromeyer-Str. 172 address: D-78467 Konstanz address: Germany phone: +49 7531 5815 0 fax-no: +49 7531 5815 99 e-mail: ralfs(a)comtec.de nic-hdl: RS27-RIPE mnt-by: DENIC-P changed: knocke(a)nic.de 941212 source: RIPE person: Dieter Schaefer address: GEZE GmbH & Co address: Siemensstr. 21-29 address: D-71229 Leonberg address: Germany phone: +49 7152 203 384 fax-no: +49 7152 203 310 nic-hdl: DS13-RIPE mnt-by: DENIC-P changed: cp(a)deins.Informatik.Uni-Dortmund.DE 930702 changed: jens(a)nic.de 950203 source: RIPE person: Alfred Schaefer address: Blaser Swisslube AG address: CH-3415 Hasle-Ruegsau phone: +41 34 61 61 61 fax-no: +41 34 61 41 93 changed: fm(a)eunet.ch source: RIPE person: Ralf Schaefer address: Comtec GmbH address: Max-Stromeyer-Str. 172 address: D-78467 Konstanz address: Germany phone: +49 7531 58150 fax-no: +49 7531 581599 e-mail: ralf(a)comtec.de changed: ip(a)Germany.EU.net 950821 source: RIPE person: Thomas Schaefer address: TomArts GbR address: Tettnanger Str 355 address: D-88214 Ravensburg address: Germany phone: +49 751 769233-0 fax-no: +49 751 769233-9 e-mail: t-bone(a)bodensee-surfer.de nic-hdl: TS39-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: wb(a)xlink.net 950823 source: RIPE person: Sebastian Schaefer address: Turmairstr. 6 address: 82166 Lochham address: germany phone: +49 89 8211019 fax-no: +49 89 8211499 e-mail: seban(a)x3network.net nic-hdl: SS34-RIPE changed: horn(a)ecrc.de 950824 source: RIPE person: Helmut Schaefer address: Wellpappe Ansbach address: Robert-Bosch-Str. 3 address: D-91522 Ansbach/Brodswinden address: Germany phone: +49 981 188107 e-mail: postmaster(a)anspack.de nic-hdl: HS93-RIPE mnt-by: DENIC-P changed: jens(a)nic.de 951010 source: RIPE person: Friedrich-Carl Schaefer address: Tellux Dr. Schaefer GmbH address: Vivaldistr. 13 address: D-76448 Durmersheim address: Germany phone: +49 7245 9304 0 fax-no: +49 7245 9304 21 e-mail: fcs(a)tellux.de nic-hdl: FS42-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: ib(a)xlink.net 951012 changed: nipper(a)xlink.net 951017 source: RIPE person: Klaus W. Schaefer address: TCS Traffic Consult & Services GmbH address: Bahnstrasse 42-46 address: D-61381 Friederichsdorf/TS address: Germany phone: +49 6172 742 55 fax-no: +49 6172 728 21 nic-hdl: KS72-RIPE mnt-by: DENIC-P changed: jens(a)nic.de 951026 source: RIPE person: Edwin Schaefer address: Forschungszentrum Informatik address: Haid-und-Neu-Strasse 10-14 address: D-76131 Karlsruhe address: Germany phone: +49 721 9654 953 fax-no: +49 721 9654 959 e-mail: schaefer(a)FZI.DE nic-hdl: ES8-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: nipper(a)xlink.net 950124 changed: nipper(a)xlink.net 950309 changed: wb(a)xlink.net 951102 source: RIPE person: Alexander Schaefer address: AS Software address: Jedleseerstrasse 3 address: A-1210 Vienna address: Austria phone: +43 1 278 15 01 fax-no: +43 1 278 15 01 ext. 22 e-mail: assoft(a)cso.co.at changed: richard.prinz(a)cso.co.at 951108 source: RIPE person: Volker Schaefer address: CadConsult GmbH address: Bismarckstr. 142 address: D-47057 Duisburg address: Germany phone: +49 203 306 13 00 fax-no: +49 203 306 13 99 e-mail: postmaster(a)cadconsult.de nic-hdl: VS31-RIPE mnt-by: DENIC-P changed: jens(a)nic.de 951128 source: RIPE person: Dirk Schaefer address: Mannesmann Transmodal GmbH address: Rehhecke 50 address: D-40885 Ratingen-Lintorf address: Germany phone: +49 2102 97 2106 fax-no: +49 2102 97 2110 nic-hdl: DS68-RIPE mnt-by: DENIC-P changed: jens(a)nic.de 951128 source: RIPE person: Oliver Schaefer address: AEG AG address: Abt. AOI23 address: Theodor-Stern-Kai 1 address: D-60596 Frankfurt address: Germany phone: +49 69 6004019 fax-no: +49 69 6005400 e-mail: postmaster(a)aoiffm.de nic-hdl: OS23-RIPE mnt-by: DENIC-P changed: jens(a)nic.de 951205 source: RIPE person: Volker Schaefer address: CadConsult GmbH address: Bismarckstr. 142 address: D-47057 Duisburg address: Germany phone: +49 203 3061300 fax-no: +49 203 3061399 changed: ip(a)Germany.EU.net 951213 source: RIPE person: Wilhelm Schaefer address: Dr. A. Koenig D.Heyne GbR address: Wiclefstrasse 47 address: D-10551 Berlin address: Germany phone: +49 30 396017 51 fax-no: +49 30 396017 26 e-mail: w_sch(a)mind.de nic-hdl: WS15-RIPE notify: guardian(a)xlink.net mnt-by: DENIC-P changed: lillge(a)maz.net 940906 changed: knocke(a)nic.de 941128 changed: alf(a)wysiwyg.in-berlin.de 951024 changed: wb(a)xlink.net 951228 source: RIPE person: Michael Schaefer address: transtec AG address: Abteilung ZD-HW address: Waldhoernlestr. 18 address: 72072 Tuebingen address: Germany phone: +49 7071 703 179 fax-no: +49 7071 703 139 e-mail: Michael.Schaefer(a)transtec.de changed: Michael.Schaefer(a)transtec.de 960102 source: RIPE person: Michael Schaefer address: Transtec AG address: Waldhoernlestrasse 18 address: D-72072 Tuebingen address: Germany phone: +49 7071 703 179 fax-no: +49 7071 703 139 e-mail: schaefer(a)transtec.de nic-hdl: MS124 mnt-by: DENIC-P changed: nipper(a)xlink.net 940217 changed: knocke(a)nic.de 941128 changed: pantring(a)nic.de 960109 source: RIPE person: Holger Schaefer address: CCP GmbH address: Schulze-Delitzsch-Str. 8 address: D-70771 Leinfelden-Echterdingen address: Germany phone: +49 711 975650 fax-no: +49 711 7545989 e-mail: schaefer(a)ccp.de nic-hdl: HS135-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: ib(a)xlink.net 960115 source: RIPE person: Alfred Schaefer address: Blaser Swisslube AG address: address: address: CH-3415 Hasle-Ruegsau phone: +41 34 61 61 61 fax-no: +41 34 61 41 93 nic-hdl: AS193-RIPE changed: msr(a)eunet.ch 960123 source: RIPE person: Joerg Schaefer address: UUCP-Freunde Lahn e.V. address: c/o Joerg Schaefer address: Weidigstr. 5 address: D-35396 Giessen address: Germany phone: +49 641 54606 fax-no: +49 641 53272 e-mail: postmaster(a)lahn.de e-mail: joscha(a)atab.lahn.de nic-hdl: JS192-RIPE mnt-by: DENIC-P changed: sb(a)deins.Informatik.Uni-Dortmund.DE 930623 changed: rv(a)Informatik.Uni-Dortmund.DE 930927 changed: poldi(a)dfn.de 940613 changed: jens(a)nic.de 960206 source: RIPE person: Marc Schaefer address: ALPHANET address: Battieux 6c address: CH-2013 Colombier phone: +41 38 41 29 29 e-mail: schaefer(a)alphanet.ch nic-hdl: MS234-RIPE changed: fm(a)eunet.ch 960221 source: RIPE person: Andre Schaefer address: Sommer Allibert-Lignotock GmbH address: Friesstrasse 26 address: D-60388 Frankfurt address: Germany phone: +49 69 41081 fax-no: +49 69 4108427 changed: ip(a)Germany.EU.net 960319 source: RIPE person: Philipp Schaefer address: Kochan & Partner address: peppermind-Network Neue Medien address: Hirschgartenallee 25 address: D-80639 Muenchen address: Germany phone: +49 89 178 601 58 e-mail: pschaefer(a)mail.tnet.de nic-hdl: PS176-RIPE mnt-by: DENIC-P changed: hostmaster(a)nic.de 960322 source: RIPE person: Peter Schaefer address: Landesgewerbeamt Baden-Wuerttemberg - IFEX address: Willi-Bleicher-Strasse 19 address: D-70174 Stuttgart address: Germany phone: +49 711 123 2773 fax-no: +49 711 123 2587 nic-hdl: PS177-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: handke(a)xlink.net 960322 source: RIPE person: Eike Schaefer address: Bausoft GmbH address: Friedhofstr. 72 address: D-63263 Neu-Isenburg address: Germany phone: +49 6102 329011 fax-no: +49 6102 320737 e-mail: esc(a)bausoft.de nic-hdl: ES70-RIPE mnt-by: NACAMAR-NOC changed: trede(a)nacamar.net 960415 source: RIPE person: Peter Schaefer address: Netart address: Rosenberg Strasse 106 address: D-70193 Stuttgart address: Germany phone: +49 711 63620-51 fax-no: +49 771 63620-53 e-mail: postmaster(a)webart.de nic-hdl: PS109-RIPE notify: guardian(a)space.net mnt-by: DENIC-P changed: svb(a)space.net 960507 source: RIPE person: Robert Schaefer address: Pro Familia e.V. address: Stresemannallee 3 address: D-60596 Frankfurt address: Germany phone: +49 69 639002 fax-no: +49 69 639852 nic-hdl: RS257-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: nipper(a)xlink.net 960618 source: RIPE person: Ulrich Schaefer address: CSN Computer Consulting GmbH address: Braeuhausstrasse 8 address: D-80331 Muenchen address: Germany phone: +49 89 290145 0 fax-no: +49 89 224916 nic-hdl: US68-RIPE notify: guardian(a)xlink.net mnt-by: XLINK-MNT changed: neg(a)xlink.net 960624 source: RIPE jade$ _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

3 4

FYI: I changed the lookup behavior
by David.Kessens＠ripe.net 17 Jul '96

17 Jul '96

Dear all, I have changed the 'whois' lookup behavior from the 'best guess' method to an exact match as requested by most people. Kind regards, David K. ---

1 0

Re: Problems with RIPE database
by rensvp＠renater.fr 17 Jul '96

17 Jul '96

Dear David, >> rensvp(a)renater.fr writes : >> >> Do you have any explanations for this problem ? > I have not an explanation (yet). You can use the old server that is > running on port 4400 as a temporary solution. > I am currently investigating what is going wrong. I will inform you when > I have found the solution. > I would like to know one more thing: are the objects new objects that you > have recently put in the RIPE database or are these already older ? > David K. Thanks a lot for your fast answer and your help. The objects have been recently created (7th of July) in the RIPE database. Franck SIMON RENATER

2 1

Problems with RIPE database
by rensvp＠renater.fr 15 Jul '96

15 Jul '96

Hello, One of our program which automatically generates route objects in the RIPE database crashes because of a 'strange' answer of the ripe database. I have recently allocated the following block 194.254.220.0 - 194.254.235.0 for one of our site. So the object generated in the RIPE database is: inetnum: 194.254.220.0 - 194.254.235.0 ... So when I make the following request: whois 194.254.220.0 I get: inetnum: 194.254.220.0 - 194.254.235.0 I get the same answer for the following addresses: 194.254.220,221,222...227 However, If I do: whois 194.254.228.0 I get: inetnum: 194.254.0.0 - 194.254.255.255 I get the same answer for the following addresses: 194.254.228,229...235 while I should get: inetnum: 194.254.220 - 194.254.235.0. (The whole block 194.254.0.0-194.254.255.0 belongs to Renater, and I allocate IP numbers from this block to our sites) So, as one of our program automatically generates route objects, It works fine for the first 8 addresses : route: 194.254.220.0/24 ... route: 194.254.221.0/24 ... route: 194.254.222.0/24 .... but it does not generate any route objects for the other addresses, because instead of generating 194.254.228.0/24 it tries to generate a route object for 194.254.0.0-194.254.255.255 Do you have any explanations for this problem ? Thanks for your help. Franck SIMON RENATER

2 1

Re: Problems with RIPE database
by zsako＠banknet.net 15 Jul '96

15 Jul '96

> From owner-db-wg(a)ripe.net Mon Jul 15 16:41:30 1996 > From: rensvp(a)renater.fr > One of our program which automatically generates route objects > in the RIPE database crashes because of a 'strange' answer of > the ripe database. > > I have recently allocated the following block 194.254.220.0 - 194.254.235.0 > for one of our site. So the object generated in the RIPE database is: > > inetnum: 194.254.220.0 - 194.254.235.0 Are you sure this is what you wanted to assign? Was it not: inetnum: 194.254.220.0 - 194.254.235.255 ^^^ ? > ... > > So when I make the following request: > > whois 194.254.220.0 I get: > > inetnum: 194.254.220.0 - 194.254.235.0 > > I get the same answer for the following addresses: 194.254.220,221,222...227 > > However, If I do: > > whois 194.254.228.0 I get: > > inetnum: 194.254.0.0 - 194.254.255.255 > > I get the same answer for the following addresses: 194.254.228,229...235 > while I should get: inetnum: 194.254.220 - 194.254.235.0. > > (The whole block 194.254.0.0-194.254.255.0 belongs to Renater, and I allocate IP > numbers from this block to our sites) > So, as one of our program automatically generates route objects, It works fine for > the first 8 addresses : > > route: 194.254.220.0/24 > ... > route: 194.254.221.0/24 > ... > route: 194.254.222.0/24 .... > BTW: Why do you add so many /24s, wouldn't aggregation be possible? > but it does not generate any route objects for the other addresses, because instead > of generating 194.254.228.0/24 it tries to generate a route object for > 194.254.0.0-194.254.255.255 > > Do you have any explanations for this problem ? > > Thanks for your help. > > Franck SIMON > RENATER > Best regards, Janos Zsako

1 0

RE: Announcement: new whois server in production+new features
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 15 Jul '96

15 Jul '96

Hi David, congratulations, nice new features !!! However, I guess this is rather a bug, isn't it ;-) Querying for "christian unknown" seems to bring a list of all Christians instead of "No entries found", or how should I formulate an explicit "givenname surname" query ? Regards, Christian

4 3

Announcement: new version of prtraceroute
by David.Kessens＠ripe.net 11 Jul '96

11 Jul '96

Dear all, A new version of prtraceroute is available from: ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta6.tar.gz This version fixes a problem that caused the program to show a [?] instead of an [ERROR] line in certain cases. It also has support for the new RIPE whois server that is installed today (and is backwards compatible with previous versions). It is highly recommended to upgrade to this version since the previous versions are not compatible with the new server. Kind regards, David K. ---

1 0

Announcement: new whois server in production+new features
by David.Kessens＠ripe.net 11 Jul '96

11 Jul '96

Dear all, First of all, it is recommended for everybody to read the *whole* announcement. I have just put the new RIPE database whois server in production. The new server has a couple of new features (and bug fixes): - twice the speed for any classless lookups - the lookup algoritm is changed such that: Matyas Matyas can finally be found and also Daniel David hasn't problems anymore with finding himself in the database - email addresses in the person objects are now also indexed and can thus be used as a search key from now on. - unlimited number of matches allowed. You can now find all Davids in the RIPE database And then the *BONUS* feature (made in France during my vacation!): - Inverse lookup has been implemented, that is: $ whois -h whois.ripe.net -T limerick -i author MN131 will give you all limericks written by Mike Norris (as long as his NIC handle is used, else try the same search with 'Mike Norris' as the key) $ whois -h whois.ripe.net -T route -i origin AS3333 will give you all routes with origin AS AS3333 (this makes the ftp://ftp.ripe.net/ripe/as/db directories obsolete, and they will thus be removed) Also a comma separated list can be used as in: $ whois -h whois.ripe.net -i admin-c,tech-c,zone-c DK13-RIPE which will give you all objects that reference myself as an admin-c, tech-c or zone-c. You can use the following attributes for inverse lookups: admin-c as-exclude author as-in as-list as-out comm-list default interas-in interas-out localas mnt-by mnt-lower mnt-nfy nserver notify origin peer rev-srv tech-c zone-c Furthermore, the RIPE whois client program has been updated to support the new options (I finally got the chance to do some C coding ;-)). The program is now packaged with some other small C programs for use in conjunction with the RIPE database: ftp://ftp.ripe.net/tools/ripe-whois-tools-2.0.tar.gz (perl versions will be packaged together with the new release of the database software, when the updating code is also ready) You will also need to upgrade the prtraceroute in case you use this program (ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta6.tar.gz). (see also separate announcement). Finally an important note to software developers: The whois server now returns objects always in the following sequence: newline object/message newline object/message newline newline (The newline at the start is new) This change allowed for more consistency and faster code. However, I am willing to make an ugly fix in case too many tools cannot handle this corectly and need updates. Please let me know if this is indeed needed. As always: please send bug reports directly to me and I will fix the problem. Kind regards, David Kessens RIPE NCC ---- RIPE whois tools 2.0 This is a set of C programs (perl versions of the same programs are available in the RIPE database distribution) to be used in conjunction with the RIPE database. It contains the following programs: - whois The RIPE version of the whois client program. This is intended for European users as it will query a RIPE whois server with extended whois capabilities rather than a standard whois protocol server. The whois program is fully compatible with the standard whois protocol and can thus replace your default whois program. This program is aware of quite some extra flags that the standard whois doesn't support. Just try 'whois' without arguments to see an explanation of these. Please note that most of these flags are NOT supported by non RIPE whois servers. In cases where you use this client to query non RIPE whois servers, you should not use any of these flags. - networkupdate A program that allows updating the RIPE database with the whois protocol instead of the usual E-mail interface. This program can usually only be used by the administrators of the whois server itself. The updating mechanism is too powerfull (for now) to allow the general public to use this mechanism. The server is protected by means of an accesslist. - cryptpw Calculate a crypted password with given password and salt. This password can then be used in the 'auth:' field of maintainer objects. -----

1 0