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@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@DFN.DE 920714 changed: rv@Informatik.Uni-Dortmund.DE 920924 changed: ripe-dbm@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@DFN.DE 920714 changed: rv@Informatik.Uni-Dortmund.DE 920924 changed: ripe-dbm@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@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@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@deins.Informatik.Uni-Dortmund.DE 910919 changed: dfk@cwi.nl 910921 changed: rv@Informatik.Uni-Dortmund.DE 920508 changed: ar@deins.Informatik.Uni-Dortmund.DE 920511 changed: ripe-dbm@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@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@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@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@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@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@ibma.IPP-Garching.MPG.DE nic-hdl: LS228 remarks: surname has typo in DDN-NIC whois changed: rv@Informatik.Uni-Dortmund.DE 920503 changed: rv@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@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@eunet.co.at> 940323 changed: knocke@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@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@SWS-Ratingen.DE nic-hdl: DS5-RIPE mnt-by: DENIC-P changed: afs@Germany.EU.net 930625 changed: rv@Informatik.Uni-Dortmund.DE 930824 changed: knocke@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@comtec.de nic-hdl: RS27-RIPE mnt-by: DENIC-P changed: knocke@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@deins.Informatik.Uni-Dortmund.DE 930702 changed: jens@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@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@comtec.de changed: ip@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@bodensee-surfer.de nic-hdl: TS39-RIPE notify: guardian@xlink.net mnt-by: XLINK-MNT changed: wb@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@x3network.net nic-hdl: SS34-RIPE changed: horn@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@anspack.de nic-hdl: HS93-RIPE mnt-by: DENIC-P changed: jens@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@tellux.de nic-hdl: FS42-RIPE notify: guardian@xlink.net mnt-by: XLINK-MNT changed: ib@xlink.net 951012 changed: nipper@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@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@FZI.DE nic-hdl: ES8-RIPE notify: guardian@xlink.net mnt-by: XLINK-MNT changed: nipper@xlink.net 950124 changed: nipper@xlink.net 950309 changed: wb@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@cso.co.at changed: richard.prinz@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@cadconsult.de nic-hdl: VS31-RIPE mnt-by: DENIC-P changed: jens@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@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@aoiffm.de nic-hdl: OS23-RIPE mnt-by: DENIC-P changed: jens@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@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@mind.de nic-hdl: WS15-RIPE notify: guardian@xlink.net mnt-by: DENIC-P changed: lillge@maz.net 940906 changed: knocke@nic.de 941128 changed: alf@wysiwyg.in-berlin.de 951024 changed: wb@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@transtec.de changed: Michael.Schaefer@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@transtec.de nic-hdl: MS124 mnt-by: DENIC-P changed: nipper@xlink.net 940217 changed: knocke@nic.de 941128 changed: pantring@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@ccp.de nic-hdl: HS135-RIPE notify: guardian@xlink.net mnt-by: XLINK-MNT changed: ib@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@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@lahn.de e-mail: joscha@atab.lahn.de nic-hdl: JS192-RIPE mnt-by: DENIC-P changed: sb@deins.Informatik.Uni-Dortmund.DE 930623 changed: rv@Informatik.Uni-Dortmund.DE 930927 changed: poldi@dfn.de 940613 changed: jens@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@alphanet.ch nic-hdl: MS234-RIPE changed: fm@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@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@mail.tnet.de nic-hdl: PS176-RIPE mnt-by: DENIC-P changed: hostmaster@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@xlink.net mnt-by: XLINK-MNT changed: handke@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@bausoft.de nic-hdl: ES70-RIPE mnt-by: NACAMAR-NOC changed: trede@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@webart.de nic-hdl: PS109-RIPE notify: guardian@space.net mnt-by: DENIC-P changed: svb@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@xlink.net mnt-by: XLINK-MNT changed: nipper@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@xlink.net mnt-by: XLINK-MNT changed: neg@xlink.net 960624 source: RIPE jade$ _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@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 _____________________________________________________________________________
Dear Joachim,
Joachim Schmitz writes :
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?
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) And the software only looks for 'Schaefer' as can be seen from your result. 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. - 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. - 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). People often make mistakes with this: They don't use the initials, they only use one initial instead of more, they use initials with dots and without. Domain name (queries) may end with a dot or not. You can probably find more examples yourself. - this problem will not happen anymore when we only allow NIC handles in the 'tech-c:/admin-c:/zone-c:' fields. Conclusion: This problem only affects incorrect objects. If I make fix, life becomes more difficult when looking for other incorrect objects :-(. It's up to the RIPE community to decide if it useful to change this behavior. David K. ---
Dear David, you wrote:
From: David.Kessens@ripe.net Message-Id: <9607171550.AA01322@belegen.ripe.net> Subject: Re: another lookup problem To: noc@noc.dfn.de Date: Wed, 17 Jul 1996 17:50:50 +0200 (MET DST) Cc: db-wg@ripe.net
Joachim Schmitz writes :
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?
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)
And the software only looks for 'Schaefer' as can be seen from your result. Obviously clear. It was my fault not to check whether a valid entry for "U. Schaefer" existed or not. It took me by surprise because I am used to another behaviour: If an entry is not found in a database I get a message telling me that it is not found - and not all entries which are somehow similar. I had problems with this behaviour before and simply forgot.
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. I agree with you. I do not enter objects with abbreviations into the RIPE database.
- 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. I completely agree
- the software should have found 'U. Schaefer' if the object existed (and nothing more, see algoritm above) I again agree
- 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 would not like to have trailing dots included.
People often make mistakes with this:
They don't use the initials, they only use one initial instead of more, they use initials with dots and without. Domain name (queries) may end with a dot or not. You can probably find more examples yourself.
- this problem will not happen anymore when we only allow NIC handles in the 'tech-c:/admin-c:/zone-c:' fields.
Conclusion:
This problem only affects incorrect objects. If I make fix, life becomes more difficult when looking for other incorrect objects :-(.
It's up to the RIPE community to decide if it useful to change this behavior.
Come on - no insult was meant. An incorrect object needs no additional checking to determine degrees of incorrectness or how the correct entry could possibly look like. I am just wondering now whether the database should give all information (all people named '.* Schaefer' regexp) if it has none (no 'U Schaefer' after removing the dot). The first approach is advantageuos if you are not sure about the complete name - you get all and just pick the one you really want. However, this makes it more difficult to immediately decide whether there is actually NO entry fitting the search pattern. I would like to know how the working group people think about this. Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@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 _____________________________________________________________________________
Schmitz@rus.uni-stuttgart.de (Joachim Schmitz) writes: ... I am just wondering now whether the database should give all information (all people named '.* Schaefer' regexp) if it has none (no 'U Schaefer' after removing the dot). The first approach is advantageuos if you are not sure about the complete name - you get all and just pick the one you reall y want. However, this makes it more difficult to immediately decide whether there is actually NO entry fitting the search pattern.
I would like to know how the working group people think about this.
Joachm, David, I think that the query should not be 'generalised' automagically if an object matching all the keys in the query cannot be found. As Joachim states correctly there is an important functionality in having a "not found" result. It should be up to the user to generalise the query by dropping keys if they wish. Automatic 'query modification' is not needed with a database that has such a short response time. Daniel
Daniel,
Daniel Karrenberg writes :
Schmitz@rus.uni-stuttgart.de (Joachim Schmitz) writes: ... I am just wondering now whether the database should give all information (all people named '.* Schaefer' regexp) if it has none (no 'U Schaefer' after removing the dot). The first approach is advantageuos if you are not sure about the complete name - you get all and just pick the one you reall y want. However, this makes it more difficult to immediately decide whether there is actually NO entry fitting the search pattern.
I would like to know how the working group people think about this.
Joachm, David,
I think that the query should not be 'generalised' automagically if an object matching all the keys in the query cannot be found. As Joachim states correctly there is an important functionality in having a "not found" result. It should be up to the user to generalise the query by dropping keys if they wish. Automatic 'query modification' is not needed with a database that has such a short response time.
I have tried to explain in my previous mail why this 'problem' happened. I showed that it is a special case. I showed that it was a special case with specific (incorrect) objects that should not even be in the database but are there because of louzy syntax checking (that is fixed in the next release). I also showed that the problem in fact only happens in the case that objects reference such objects but *don't* exist. The software will find the correct objects when the incorrect object exists (and only the referenced object). The behavior is not that different from the previous version of the database. The trailing dot removing is new. The skipping of too small keys is not new (try 'whois -p 4400 -h whois.ripe.net U Schaefer', this is the old server). I think that it is reasonable to skip keys that are only one character long. I think it is reasonable to remove trailing dots (this is much easier for users for 99.99% of the cases). Yes, this choice is a trade off. The choice you propose is that we accept any key, no matter how short. This also has some severe disadvantages. Do you want to let the whois server behave different for queries as: 'U. Schaefer' OR 'U Schaefer' 'ripe.net' OR 'ripe.net.' 'John F. Kennedy' OR 'John Kennedy' (are you always sure if somebody used his/her initials and which they are?) notes for all examples: 1) the database *will* return only exact matching objects when they exist. 2) only one character keys (as with the previous version of the software) possible followed by dots are dropped. 3) the other 'fuzzy logic' matching (skip keys that don't exist) has been removed as announced in a previous mail and asked for by the database working group. This was the question (and may be answered with yes), David K.
participants (3)
-
Daniel Karrenberg -
David.Kessens＠ripe.net -
Schmitz＠rus.uni-stuttgart.de