- db-wg - mailman.ripe.net

interesting person entry... (followup)
by Schmitz＠rus.uni-stuttgart.de 26 Sep '96

26 Sep '96

Dear colleagues, regarding empty input lines in the RIPE database: rubin$ egrep '^\*ad: *$' ripe.db.pn | wc -l 13442 rubin$ egrep '^\*..: *$' ripe.db.* | wc -l 15522 (with the database as of this morning around 2:10 am) I estimate this really should be changed... Regards Joachim _____________________________________________________________________________ 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 _____________________________________________________________________________

1 0

RE: RE: HELP! 'networkupdate', diskussion on short names of attributes
by Markus Bock 20 Sep '96

20 Sep '96

Hi all ! Contents: --------- 1. Thanksgiving for quick response 2. More about the problem with 'networkupdate' 3. Comments on short names of attributes 4. Comments on whois -i option 5. Question on destination for emails in 'RIPE DB' context 1. Thanksgiving for quick response ================================== At first I would like to thank - Wilfried Woeber, UniVie/ACOnet - Geert Jan de Groot, RIPE NCC - Carol Orange, RIPE NCC and specially - David Kessens who gave me quick response to my 'cry for help'. Thank you very much for your suggestions and for taking time to think about that problem with the 'networkupdate' client programm. Below you can read more about the progress in that case. And no, there is no reason to say sorry for a 'delayed response'. I'm pleased about your quick and helpful reactions. Thank you again! 2. More about the problem with 'networkupdate' ============================================= Below i repeat parts of David Kessens answer ... > Hi Markus, > > Markus Bock writes : > > > > For writing database front ends which manipulate and visualisize > > the stored data we want to use the 'networkupdate' program to > > have access to the database from different workstations via LAN. > This function is indeed present for this purpose. Yes, great. I think with the direct network update-method one has many potentialities to develope client-server based applications with a two task architecture like you see in the sketch below (just an example). ----------------- client-area | application | ----------- ----------------- | networkupdate | ----------------- | ^ v | communication drivers & protokolls // // network ======================================== \\ \\ // || VV communication drivers & protokolls | ^ v | ----------------- server-area | DB-server | ----------- | whoisd | ----------------- | | ----------------- / \ / \ ________ ___________ (________) (___________) | DB | | DB | | source | | source | | XXXX | | OWN | -------- ----------- > Maybe I make something wrong or this effect has something to do with > > running under Slowaris 2.5 ... ? > May be, may be not. Could you try the C version of networkupdate > (available from ftp.ripe.net/tools/whois-tools*) and see if the same > problem happens ? Yes I did it. The same problem happens NOT. I performed several tests with the C version and everything is working fine giving the estimated results. Just for information: --------------------- I had to do the following changes inside the makefile of the C versions of the ripe whois tools to compile it successful at our site under Solaris 2.5 with gcc: - define '-DSYSV' added - additional LIBS 'LIBS= -lresolv -lsocket -lnsl' added - changing the syntax to call install # install: ${PROG} # $(INSTALL) -c ${DESTDIR} -s -m 755 ${PROG} networkupdate # $(INSTALL) -c ${MANDIR}/whois.1 -m 444 whois.man > Could you try 'networkupdate -h whois.ripe.net'. You should get a message > back that tells you that you are not authorized to network updates. The > problem is problably in the client side of the software if you don't get > this message. Yes, I did it. - With the perl version I didn't received the message that tells me that I'm not authorized to do network updates. There is an analogical problem like I described in my 'cry for help'. 'networkupdate' terminates immediately. - With the C version I received the estimated message % ERROR: ***You are not authorized to do network updates***. With this results I agree with you that the problem is problably in the client side of the software. I tried to find out what is potentially wrong in the software by taking the examples for a client and a server from L. Walls camel book and comparing it with the RIPE DB SW (I assume that the same mechanisms are used by the RIPE DB SW). But I was still not able to change it in that way that these examples are able to handle the input of multiple lines (I'm not familar with 'command buffering or not' stuff) or to produce an analogical failure like decribed above. So I have no further result with this case. Has anyone tested the perl version of the networkupdate programm succesfully at his site ? If yes, in which enviroment (OS, version, HW etc.) ? > Please contact <ripe-dbm(a)ripe.net> and see if they can help you with > extra debugging code in the whoisd daemon/whois client to do a more > detailed trace of what is happening in the server software. Yes, thank you. I'll do it. > I hope this helps, > David K. > PS Please don't expect any fast responses right now since I am still busy > with moving & am not working yet. I have, however, already built a new > computer & got a ppp account at ISI so I am not completely > disconnected anymore ;-). Yes, thank you again. Your help enables me to go sucessfully on with my work. Also this gives me the opportunity to wish you success and good luck for your future at ISI. 3. Comments on short names of attributes ======================================== First: ------ While testing the RIPE DB for use to store own data objects I examined the following cases: Assume that you have to store 30 or more new database objects with about 300 (or more) new attributes in a (SPLIT) RIPE database (I already did it). Because you will have problems to find sensefull short names for attributes you use a numbering scheme like this: # DB-object dummy A1 ATTR A1 dummy_longname_1 ATTR A2 dummy_longname_2 ATTR A3 dummy_longname_3 # DB-object dummy A1 OBJ A1 ATSQ A1 A2 A3 OBJ A1 MAND A1 OBJ A1 MULT A2 A3 OBJ A1 UNIQ A1 OBJ A1 KEYS A1 Seems ok. *** But be careful. Don't use uppercase letters *** for naming database objects and attributes *** in a SPLIT database. The side effects are that at first everything is working fine (indexing, dbupdate updates via email etc.). The data will be stored correctly. But if you query the database via whois and whoisd you ever get the message that will be displayed if no match was found (have a look in your ripedb-config file). What happened ? After I had a look at the source code of the whoisd I think one can find the explanation in this section # sub findsplitdbs { # local(*keys, @preselection)=@_; # local(@searchdb)=(); # # print STDERR join(" ", keys %CLASSLESSDBS), "\n"; # @preselection=grep($CLASSLESSDBS{$_}, @preselection) if (scalar(grep(/^$VALIDPREFIXKEY$/o, @keys))==scalar(@keys)); # # # # and now we are going to do something really smart... # # and trickey things # local(@upperkeys)=@keys; # grep(tr/a-z/A-Z/, @upperkeys); # # # # see comment below why we need this # local(@tmpkeys,@tmpupperkeys); # local($tmp); and so on. I think that with this the software is not able to find the datafiles, i.e. which are named by this konvention /whereever/it/is/SOURCE.db.OBJECT /whereever/it/is/SOURCE.db.OBJECT.pag /whereever/it/is/SOURCE.db.OBJECT.dir where OBJECT is in uppercase letters. Does somebody agree with me ? Second: ------- Above I wrote about a problem to find sensefull short names if you have to store many new database objects with many (many) attributes. What you have at least for this is a two letter code with all alphabetic characters (in lowercase) and all digits. So you have (26+10) * (26+10) = 1296 (I hope it is correct...) possibilities for short names. This seems to be enough. But you have still the problem to find sensefull short names for a large amount of database objects and attributes. Maybe I see a problem 'where no problem is' but I can assume that in future even the RIPE database (if it will growth by objects and attributes) will reache the border finding sensefull names for short attributes. So my questions are: - Is it possible to use in future only the long names of attributes and objects or - needs this change too much manpower and time ? >From a view of data modelling I think the short names are redundant even if I know that from a view of implementing the database and writing code they are useful (i.e. for doing syntax checks). 4. Comments on whois -i option ============================== Wow ! I really like this option. If you have a somewhat clever data modelling you can realize something like a 'where clause' which is known from SQL. Another thing is that you can realize something like a 'join' over two database objects. You just have to play a little bit around with the 'KEY' and 'REC' terms inside the definition of your database objects. 5. Question on destination for emails ===================================== in 'RIPE DB' context ==================== I don't know if the database working group is the right address to report everthing in context RIPE database. Should one better report only for i.e. problems with implementation and porting the software directly to the database maintainer at RIPE NCC <ripe-dbm(a)ripe.net> ? and on the other side Should one better report only i.e. issues about the database concepts directly to the database working group ? Is there somewhat like a rule for this ? Thanks again ! have a nice day, Markus

2 1

FYI: List of current proposals
by davidk＠ISI.EDU 20 Sep '96

20 Sep '96

Dear all, This is my latest (and last) list of active proposals. There is still appears to be enough work for the new database maintainer(s) ;-). List of current proposals: 1) AUTO NIC handles (included in 2.00 release) 2) Role object (included in 2.00 release) 3) AS macro syntax 4) inverse lookup (included in 2.00 release) 5) whois -tv 6) referral mechanism 7) INADDR 8) NEW (included in 2.00 release) 9) stronger authorization 10) extended as-in 11) stored/processed attribute 12) name tag 13) url attribute 14) syntactic cleanup 15) WWW-WAIS-database interface 16) whois -H, cgi-bin behavior and HTML formatted output 17) reference exist check 18) don't delete referenced objects You can find a more detailed description below. Please let the new database maintainer(s) know if you know of any other proposals that I forgot about, Kind regards, David K. ---- 1) AUTO NIC handles: Auto assignment of NIC handles Current state: DONE Time estimation: long Syntax: nic-hdl: AUTO-#[Initials] where: # - is an arbritary identification number Initials - optional, advises the database software to use initials for the generation of the NIC handle. will cause NIC handles to be generated automatically. The number is needed to give the possibility for autogenerating and referencing more then one person object (that doesn't have a NIC handle yet) under every condition in one RIPE database update. AUTO is used as a prefix to avoid any confusion between real NIC handles and requests for auto generating NIC handles. Example: person: NIC Handle nic-hdl: AUTO-45NH [... stuff deleted ... ] person: Nick Hansson nic-hdl: AUTO-3NH [... stuff deleted ... ] inetnum: x.y.z.0 - x.y.z.255 admin-c: AUTO-45NH tech-c: AUTO-3NH [... stuff deleted ... ] Will assign a NIC handle with Initials NH and the first free number to 'NIC Handle' and NH and the next free number to 'Nick Hansson'. It will also fill these NIC handles in the right attributes of the objects. 2) New role objects Current state: DONE Time estimation: medium Syntax: The definition of the object: - name will be 'role:' - will have the same attributes as a person object - will have a 'tech-c:' and 'admin-c:' attribute - A NIC handle will be generated just as with person objects How to reference the object: - The object can be referenced from 'tech-c' and 'zone-c:' attributes only - recursive lookups go only one level deep 3) AS macro syntax New syntax for community and AS macros Current state: nothing done, need approval of the RIPE minutes first Time estimation: very short New syntax: community: Format: <string> The <stringmust satisfy the following constraints and the constaints for as macros (see below): + It must not start with the any upper or lower case permutations of the character "A" followed by the character "S". That is, the pattern "[Aa][Ss]" is not legal at the start of a community name. + It must not be the same as any of the routing policy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) It can expected that the keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. as-macro: Format: AS-<string> The <stringmust satisfy the following constraints: + It must be at least two characters long. + It must contain only upper case letters, lower case letters, digits, or dashes (underscores (_) were dropped to avoid confusion between dashes and underscores) + It must start with a letter + It must end with a letter or digit All comparisons will be case insensitive. 4) inverse lookup Current state: DONE Time estimation: medium What is it? Inverse lookup makes it possible to find objects that match a certain key in a specified attribute. Example: whois -i admin-c,tech-c,zone-c DK13-RIPE gives all objects that have DK13-RIPE as their admin-c, tech-c or zone-c. 5) verbose templates/whois -tv Current state: data collection (from the RIPE documents) started Time estimation: short/medium, see note below Notes: - This will probably be a joint project with Merit. - The data collection part takes most time but is needed for some other projects anyway: We need documentation on all our objects for our own documentation, the RPSL IETF working group and future work to get the InterNIC and RIPE syntax synchronized. What is it? Verbose templates are meant to give more information on object templates then we give now. It is intended that 'whois -v -t inetnum' will give the syntax of the attribute (as with 'whois -t'), a short description of the attribute and a 'minimal' regular expression to give a better idea on how the attribute should look like. 6) referral mechanism Current state: No detailed proposal, nothing done Time estimation: short/medium Notes: This is not a agreed on proposal but is interesting to implement for experimenting with the topic, although it is of use for the community even in an experimental phase. More sophistacted designs might come up that will need much more time to implement and can be regarded as separate projects. What is it? We want to have an automatic referral mechanism that will make it possible that RIPE database objects refer to other whois servers and your client can then search that servers automatically. Example: domain: NL refer: WHOIS domain-registry.nl 7) INADDR reverse delegation integration with the RIPE database Current state: nothing done Time estimation: short/medium This proposal will allow for sending your reverse delegation requests directly to the RIPE database. The updated objects are sent to the reverse delegation robot after the update succeeded if a special keyword (INADDR?) is present in the Subject: line of your message. 8) NEW Current state: DONE Time estimation: short substitute the <auto-assign(a)ripe.netmail box by the keyword NEW in the update to the RIPE database. Only new objects will then be accepted for addition to the RIPE daatabase. 9) stronger authorization Current state: No proposals, nothing done, see note Time estimation: ??? Note: - Merit has a mechanism, but it is unclear if it is general enough and might need too much human intervention when dealing with a database as big as RIPE has. Also, import restrictions might disallow us to use Merit's code. No proposals on how to do this exactly are available right now. 10) extended as-in extended as-in/as-out attribute Current state: Proposal circulated, nothing done at RIPE, see note Time estimation: ???, but probably not too long if Brian Renaud's implementation is good. Note: - Brian Renaud (Merit) has made an implementation and has sent it in. I haven't had time to really look at it. It looks promising. Previous concerns that I had because this implementation required certain external tools seems like they have been addressed. What is it? See proposal by Cengiz Alaettinoglu <cengiz(a)ISI.EDUthat is circulated to the RPSL IETF working group mail list. 11) stored/processed attribute Current state: Proposal approved. Nothing implemented yet. Time estimation: short/medium What is it: Attributes added to all objects that contain a time-stamp and serial number. This allows for better knowledge on the history and age of objects. The attributes will also make the near real time mirroring more robust then it is now. In the future features like rolling back and forth to certain database states can be supported but need to be addressed in a separate project. A proposal has been circulated and appoved to the RIPE database working group. 12) name tag handle (Full name of person) data in tech-c/admin-c/zone-c attributes Current state: No detailed proposal has been made yet. Time estimation: short/medium (might be more complicated then expected right now) The proposal makes trouble shooting with disappeared person objects easier (esspecially when person might be located in a different database). The proposal als allows for non-recursive lookups in many cases when the user has enough info when seeing the name only. 13) url attribute Current state: No proposal yet Time estimation: short What is it? Attribute that can be used in any database object for references to any other site by using an url. No exact proposal has been made yet, but the idea seems to be very useful. 14) Syntactic cleanup Current state: Nothing done yet Time estimation: short/medium It is perceived by the user community as well as by the software developers for the routing registry that some of the syntax is unecessary complicated and/or makes more confusion then it solves. Therefore it was decided on the last RIPE meeting to remove the following features: - the ripe-181 line continuation will no longer be supported. People that used it will be asked to update their objects. - The syntactic sugar words will always be mandatory to avoid all kind of interesting problems (for example with deletions). The raw database file will also contain the syntactic sugar. We will announce this change long in advance to the proper lists to give people the chance to make changes to their software if necessary. 15) WWW-WAIS-database interface Current state: running implemention at GARR-NIS available Time estimation: medium What is it? Check out http://www.nis.garr.it/services/whois.html and select: 'Accesso via WAIS al servizio WHOIS' 16) whois -H, cgi-bin behavior and HTML formatted output Current state: design needs to be made Time estimation: short/medium What is it? There are already several whois client CGI scripts available, however many people believe that the HTML formatting could be done at the server side which allows for (more) consistent ouput for the users and immediate availability of new features. 17) reference exist check Current state: hooks are available in the code Time estimation: short/medium, see note below What is it? Checks if the references that are used in an object exist when doing a creation/update of an object. This is a missing feature that is mandatory in any decent database system. Note: a 100% safe check is very difficult to implement (for split databases) in the current code and will take considerable more time then the above estimate. However, the simple test will come very close to 100% and is considered to be enough for now. 18) don't delete referenced objects Current state: hooks are available in the code Time estimation: short/medium, see note below What is it? Checks if an object is referenced by other objects before deleting it. This is a missing feature that is mandatory in any decent database system. Note: a 100% safe check is very difficult to implement (for split databases) in the current code and will take considerable more time then the above estimate. However, the simple test will come very close to 100% and is considered to be enough for now. ========

1 0

proposal for inet-rtr obj extensions, for multicast, etc.
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all, (to complete a long-standing RIPE action and to make progress) please find below a modified version of a document (originally by Erik-Jan Bos) which then was describing a multicast router in a routing registry. This version proposes a more generalized approach and tries to discuss some implications, benefits and compatibility issues. It is up for discussion in the relevant RIPE working groups - in particular Routing, Mbone, (IPv6??) and DataBase. Of course any input and suggestions welcome! I would like to have your comments before and at the RIPE 25 Meeting, as well as on the mailing lists. Apologies for any rough edges, inconsistencies, omissins and typos. I'm sure we're going to change and improve this text (if this is at all perceived as a useful exercise) and before it could eventually become a RIPE Document. Best regards, 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 -------------------------------------------------------------------------- --- Start of document Generalized Description of Peering Relations in a Routing Registry Erik-Jan Bos, Wilfried Woeber Document ID: ripe-nnn September, 1996 [ adapted and extended from a previous proposal titled: ] [ ] [ A Multicast Router in the Routing Registry ] [ Erik-Jan Bos ] [ Document ID: ripe-nnn ] [ May, 1995 ] **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an extension and generalization of concepts as documented in ripe-122 (Specifying an "Internet Router" in the Routing Registry) by which it becomes possible to define peering relations in a very general way. This approach should in particular be understood to support documentation and debugging of "overlay networks" and regular routing protocol peerings at the same time. Originally this work was started to acommodate the description of a multicast capable Internet router within a routing registry. Comments and suggestions received at RIPE DB-WG sessions and private input led to the proposal to generalize the functionality. In addition to the inet-rtr specific attributes we propose the inclusion of a url: attribute, which is already proposed as an extension to all defined objects. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is already suffering from problems that used to be present in the unicast-bone several years ago, such as routing coordination (and the lack of scoping of announcements). While the Mbone is currently a focus of interest, activity, growth and coordination efforts, we expect the general concept of an overlay network that needs routing coordination to become a general issue (e.g. IPv6 tunnels). Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone in particular, and other "overlay networks" in general, could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the various different peering environments and/or overlay meshes. Furthermore, administrative details (such as contact person) and operational information (e.g. NOC info as described in role objects) are easily administered by well known procedures and become easily retrievable. Further discussion of the basic concepts led to the idea of generalizing this approach to cater for registering all sorts of peerings, with the dynamic exchange of routing information being a secondary issue. A long-term goal should be to provide the level of configuration and debugging support that is already available for maintaining external unicast routing to a broader range of routing domains. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. A Router specification a multi-protocol router in the Internet Because an Internet Router - can perform different types of routing at the same time, e.g. . IP unicast routing . multicast routing using DVMRP tunnels or PIM . IPv4/IPv6 or "general purpose" tunnels - in many situations there are defined or potential interactions between the routing domains documentation of these facts should be possible in the routing registry. 3.1 A Simple Router Object, IPv4-only, Current Definiton Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a general purpose unicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object as described in ripe-122. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which (currently) is only meaningful in the context of external IP routing. Furthermore, the ifaddr:-lines show that this router has two interfaces, connected to two different networks, and the masks used on these networks. Finally the peer attribute records the IP (Version 4) address for an external BGP peering and lists peering specific information, eg. the localas: of the peer router (AS2108) and the type and version of the EGP used (BGP4). 3.2 A Router for IPv4 and DVMRP, extending the current structure For a moment, let us assume that this box is at the same time used as a multicast router and has a DVMRP tunnel configured. One of the approaches would be to define a dedicated attribute to describe this configuration, say mpeer: for multicast peering. The router object would then look like the following example: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE While all the previously defined and well-known attributes would remain unchanged, the newly invented mpeer: line would be used to describe a DVMRP peering and showing it's peer's IP address, the treshold and metric. Again, the format and interpretation of the entries beyond the IP (Version 4) address would be specific for that attribute. The advantage of that approach is that there is no need to change the definition of exiting attributes, which in turn preserves the functionality of any tools written to understand the specific information. However, there is a couple of major disadvantages when proceeding in that direction - the most important ones being that - the object's definition and schema has to be changed whenever a new attribute for a differnet kind of peering is proposed - frequent changes of the objects schema would lead to incompatible versions of the software - eventually having a sizeable number of different attributes for the various peerings leeds to congestion of the namespace for attribute tags and (probably) to confusion and errors on the human part of the system - and (maybe the most important thing) there is currently no way to describe peerings that do not use IPv4 addresses to identify the peer, e.g. IPv6 and some other protocols 3.3 The Generalization of the Peer Description Concept Because of these reasons given in 3.2 we propose to change the concept of the peering description to become more general and extensible by moving the peering protocol identifier into the first part on the line and deriving the format and meaning from that. Thus the example object used here would look like the following: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 g-peer: BGP4 161.53.2.1 AS2108 g-peer DVMRP 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Changing the object's schema in that way raises the issue of backwards compatibility versus "cleanliness" (tools) and compatibility of possibly different versions of the software deploied at different registries. 3.4 Backwards Compatibility Discussion For the backwards compatibility we propose to define a new attribute g-peer, "generalized peering description", and eventually make the peer: attribute obsolete - as soon as the tools have been converted to understand the new format. The disadvantage is the coexistence and/or duplicate registration of BGP4 specific information in peer: and/or g-peer: lines. An alternate approach would be to stick with the peer: attribute for the BGP4 specific information and to specify all other types of peering in g-peer: attributes. While this may be an advantage in the short term, it might add complexity for the tools in the long run by requiring them to understand different attribute formats. For the different software version issue we propose to have the implementation treat any unknown peering type (and the rest of the line) as a remark. This situation should generate a warning at the time of registration or update, and there should probably a switch to instruct the software to suppress the warning or do more stringent tests. We specifically ask the maintainers of tools which are currently relying on the peer: attribute, and the RIPE- and Internet-Community in general, for guidance about these issues! All other attributes would remain as already defined for a routing registry [1]. See next chapter for the syntax definition and concepts for extension. 4. Multiprotocol Router Syntax Definition An object for a router capable of maintaining different routing protocol (or tunnel) peerings in parallel is defined here. Each of the possible attributes are shown, on a single line. The second column defines whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] peer: [obsolete] [multiple] g-peer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. [Note: For the time being this is specific for the IPv4 external routing domain. It might even be useful to move that information to a g-peer: BGP4 entry?!] ifaddr: An interface IPv4 address of the router. [Note: the current draft of this proposal does not deal with necessary or desirable changes for IPv6.] peer: obsolete, potentially useful until RR tools are changed! g-peer: A peering of the router with another router, indicating the protocol and any protocol-specific information. [Note: please refer to the next section for the protocols being proposed in this draft and the proposed mechanisms for extension] Format: <protocol-ID> <peer address> <additional information> Examples: g-peer: DVMRP 192.87.108.13 16 1 g-peer: BGP4 161.53.2.1 AS2108 g-peer: IPv6-TUN IPv6-Address IPv6-specific Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 4.1 Discussion of Application Use of this approach has already been discussed for BGP4: g-peer: BGP4 <remote-peer address> <peer AS> example: BGP4 192.87.4.6 AS2122 localAS AS2121 or even g-peer: BGP4 <remote-peer address> <peer AS> [localAS <ASnumber>] DVMRP g-peer: DVMRP <remote-peer address> <metric> <thresh> example: DVMRP 192.87.4.6 192.87.108.13 16 1 IP-over-IP g-peer: IPv4-TUN <remote-peer address> example: IPv4-TUN 192.87.4.6 or g-peer: IPv6-TUN <remote-peer address> example: IPv6-TUN IPv6-Address 4.2 Extensions * t.b.s. * [ The gist of it should be that future extensions could be incorporated by simply editing a software configuratin file to define additional protocol types and supplying the syntax checking rules. To be discussed in more detail. ] 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone-WG has already done some reviewing of a previous version of this document and they receive credits as well. We are grateful for detailed suggestions received from David Kessens (ISI, then with the RIPE-NCC) and Steve Richardson (Merit). 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document --------------------------------------------------------------------------------

2 1

Fwd: Re: About db-wg minutes
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all ! As you might know, we lost the notes for the Berlin DB-WG meeting due to a nasty act of theft. So much for the hospitality of a university... I think (hope) that the notes provided by David Kessens have already been circulated. Unfortunately I'm under too much pressure these days to do a thorough investigation. Thus, just to make sure, here it is (again?). Thanks David ! See you next week in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I include below my draft for the minutes. Feel free to change them according to your personal needs (we talk later about the bribes), See you, David K. ---- Database Working Group Chair: Wilfried Woeber Scribe: Hans Petter Holen 1. Administrative stuff Hans Petter Holen volunteered to take notes on his notebook. However his notebook computer was stolen right before he was able to E-mail the minutes to the chairman. Therefore the minutes are reengineered as best as possible by Wilfried Woeber and David Kessens. The proposed WG-agenda was accepted. 2. DB-SW report David Kessens offered the traditional database software report. The slides of the presentation can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-david-DB-REPORT.ps.gz The database has grown by 25 % in 3 months time. A new more powerfull 1.1 version is ready although not published yet since it still lacks some small pieces before it can be released as a non-beta version. Most interesting new features in addition to the already known new features are: - Hierarchical authorization for the creation of 'domain:' and 'inetnum:' objects - the extended country attribute syntax is implemented - inetnum objects can finally be sent in prefix notation - line continuation with a '\' is supported - many changes to ease installation - many bug fixes The hierarchical authorization needed some decisions to be taken by the community on how the hierarchy of the objects would be defined: The following was decided: For 'domain:' objects: - creation of TLD domain objects need intervention of the RIPE NCC - the parent object is the biggest domain that still completely matches the domain of the object to be added. For 'inetnum:' objects: - objects can be created automatically if no parent object could be found For 'route:' objects: [ Wilfried, I need some help here, my notes are not clear ... ] No final decisions were made since all proposals had disadvantages - Do the authorization as specified in the 'mnt-by:' attribute in the origin AS of the route object. Problem: People can still create route objects with other origin ASs It seems that we need some more thinking before we can come up with a nice solution. Automatic NIC handle generation: A proposal was done with special keywords AUTO and a different syntax for more experienced users that would want to have a bit more control. It was perceived that this was unnecessary complicated. We finally found a solution that provides a single mechanism for dealing with all easy and more complicated cases: nic-hdl: AUTO-#[Initials] where: # - is a random number Initials - optional, advises the database software to use initials for the generation of the NIC handle. will cause NIC handles to be generated automatically. The number is needed to give the possibility for autogenerating and referencing more then one person object under every condition in one RIPE database update. AUTO is used as a prefix to avoid any confusion between real NIC handles and requests for auto generating NIC handles. Role objects We finally reached agreement on the role object. The definition of the object: - name will be 'role:' - will have the same attributes as a person object - will have a 'tech-c:' and 'admin-c:' attribute - A NIC handle will be generated just as with person objects How to reference the object: - The object can be referenced from 'tech-c' and 'zone-c:' attributes only - recursive lookups go only one level deep Finally we decided on a proposal by Cengiz to clean up some syntactic problems in the routing registry part of the software: - the ripe-181 line continuation will no longer be supported. People that used it will be asked to update their objects. - The syntactic sugar words will always be mandatory to avoid all kind of interesting problems (for example with deletions). The raw database file will also contain the syntactic sugar. We will announce this change long in advance to the proper lists to give people the chance to make changes to their software if necessary. 3. RADBServer report by Gerald Winters [ for wilfried or Gerald Winters <gerald(a)merit.edu>, his slides were not on the Merit ftp server ] 4. Extended syntax for communities and as macros [ Wilfried: please check the conditions, I was not sure if we decided on a minimal length of the string ] Recently Brian Renaud posted a proposal to the RIPE database working group on an extension of the possible characters that could be used for communties and as macros. Gerald Winters presented the proposal to the RIPE database working group and asked for input of the working group on some unresolved minor issues. The working group found consensus on the following new syntax: community: Format: <string> The <string> must satisfy the following constraints and the constaints for as macros (see below): + It must not start with the any upper or lower case permutations of the character "A" followed by the character "S". That is, the pattern "[Aa][Ss]" is not legal at the start of a community name. + It must not be the same as any of the routing policy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) It can expected that the keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. as-macro: Format: AS-<string> The <string> must satisfy the following constraints: + It must be at least two characters long. + It must contain only upper case letters, lower case letters, digits, or dashes (underscores (_) were dropped to avoid confusion between dashes and underscores) + It must start with a letter + It must end with a letter or digit All comparisons will be case insensitive. The slides of the presentation can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-renaud-DB-syntax.ps.gz 5. www interface based on WAIS by Antonio Blasco Bonito Blasco presented a new user interface for the world wide web developed at GARR-NIS. The underlying technology was based on WAIS. The interface provides interesting features that are not possible with the current 'whois' or WAIS interface like looking up arbitrary strings but with a higher level of granularity then we are used to; per object type and OR'ed and AND'ed searches are possible. Furthermore, the software automatically detects URL's in the objects and generates a pointer to the site in the URL. The slides can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-bonito-DB-waisinterface.ps.gz The community expressed their interest in the interface and asked the RIPE NCC to implement this software as soon as possible even when the interface would not always be consistent with the layout of the new RIPE web interface. Carol Orange told that the RIPE NCC would try to integrate the interface with the new web site, but that the resources are very limited and that the interface would need to wait until the launch of the new RIPE website. 6. Review of active proposals and priorities David Kessens showed a slide on the proposals that were done in the past. Since the meeting was running out of time, it was then decided that David would send a list of active proposals to the mailing list and to provide a mechanism for the community to decide on the priorities. 7. AOB None. Meeting closed. List of new actions: Action 24.? on David Kessens Implement the automatic NIC handle assignment in the RIPE database with the syntax as decided as decided on during this working group session. Action 24.? on David Kessens Send a list of active proposals to the mailing list and provide a mechanism for the community to decide on the priorities --------------------------------------------------------------------------------

1 0

Draft/Proposed Agenda for the DB-WG Meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 17 Sep '96

17 Sep '96

This is the 1st (rough) proposal of a draft agenda for the Database-WG at RIPE 25 in Amsterdam. There is a considerable amount of contention for slot-time, so we're not going to have more than 90 minutes this time. Thus I propose to put the effort on structural things, this time and leave the details for the DB-WG list after the meeting. Like: - approaches for better data consistency (if any :-) - documentation - priorities Apologies if I missed something obvious... As usual, comments, additions, deletions welcome. See you, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed/Draft Agenda: Database-WG, RIPE 25, Amsterdam, NL ---------------------------------------------------------- A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - recent changes, V2.0 - new features: experience, feedback C. DB consistency and sanity checks - at time of transaction (create/modify) - at regular intervals - input from other WGs - input from the NCC (address space handling) - RIPE/(NIC)-Handle space, special cases, like ROLExxx-RIPE, RIPExxx-yyy, AUTOxxx-RIPE D. Inverse lookup discussion - recursive lookup on by default, should this change? - extending the list of attributes that can be use in -i lookup? E. Documentation - structure and contents as proposed by the NCC - user input F. New functionality - things on the consolidated wish-list - url handling - inet-rtr object extension Y. General input from other WGs Z. AOB Draft 1.0, 17-SEP-1996, WW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

HELP! 'networkupdate' fails
by Markus Bock 11 Sep '96

11 Sep '96

Hello ! Actually I'm testing the ripe-dbase-software (release 2.03). In near future we want to use the ripe-dbase-software to store internal data (i.e. customer data, infrastructure data ...) and to run a secondary of the ripe database at our site. We're running under Solaris 2.5 with the special perl4.036-hack (from here many thanks to Peter Haag) which is avaiable on your ftp-server. Everything is running fine, i.e - all kinds of queries - handling of new, own database objects - running with different sources in split-mode - set-up of the database. For writing database front ends which manipulate and visualisize the stored data we want to use the 'networkupdate' program to have access to the database from different workstations via LAN. But it is not working at our side, it is not possible to forward objects via STDIN to the whoisd after calling the networkupdate programm. 'whoisd -V -D' gives me the following trace: (europa is the server-machine, x11 is the client-machine) # europa: whoisd -V -D # whoisd daemon (6827) - running in debug mode # whoisd daemon (6827) - will connect to port: 43 with protocol: 6 # whoisd daemon (6827) - changing (UID,GID) from: (0,1 14 12 9 8 7 6 5 4 3 2 0 1) to: (500,200) # whoisd daemon (6827) - changed (UID,GID) to: (500,200 14 12 9 8 7 6 5 4 3 2 0 1) # (6832) child connection x11.NIC.DTAG.DE (194.25.1.107) # (6832) got in parse # (6832) left parse, searchstring: # (6832) whoisd called with flags:U:Vnp2.0 # (6832) whoisd lookup: # (6832) whoisupdate(name:'x11.NIC.DTAG.DE',ip:'194.25.1.107',log:'mb localhost') called # (6832) checking 194.25.1.107=~ /194.25.1.107/ # (6832) update from: 194.25.1.107 accepted, regular: 194.25.1.107 # (6832) whoisupdate accepted # (6832) exit connection [194.25.1.107] After calling 'networkupdate - h europa' on the client-machine it terminates immediately! After accepting the whoisupdate the connection is terminated by the whoisd! I checked our ripedb-config file more than one time and I thing that everything inside is correct. Maybe I make something wrong or this effect has something to do with running under Slowaris 2.5 ... ? Or is there a tricky way to setup the possibility for networkupdates ? Is somebody able to help me ? Kind regards Markus

3 2

RE: HELP! 'networkupdate' fails
by Wilfried Woeber, UniVie/ACOnet 09 Sep '96

09 Sep '96

>But it is not working at our side, it is not possible to forward >objects via STDIN to the whoisd after calling the networkupdate >programm. I think there was a brief note somewhere in the release-notes (might have been somewhere else) which hinted at some special actions to enable that functionality. I think there is some address filters somewhere ? I might be barking at the wrong tree, of course. 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

RIPE Database Workshop
by Carol Orange 20 Aug '96

20 Aug '96

W O R K S H O P A N N O U N C E M E N T R I P E D A T A B A S E 2.0 ------------------------------ MONDAY, SEPTEMBER 23, 1996 9.00 - 12.00 In conjunction with the 25th RIPE Meeting to be held at the Nikhef Institute in Amsterdam, the RIPE NCC will hold a workshop in which the features of the new release of the RIPE Database package will be introduced. The workshop will be held at the RIPE meeting location. Topics to be covered in the workshop include: + Hierarchical authorization + Automatic NIC-handle mechanism + Role objects + Classless update and lookup mechanisms + Reverse lookup of objects + Near real time mirroring Where applicable, examples will be used to illustrate how the features above can best be employed. Common questions regarding the use of each feature will also be discussed. Time will be reserved to address the questions of workshop attendees. The test database will be set up during the meeting with the examples covered in the workshop. Attendees can try things out during the RIPE meeting, and address any questions that may arise to RIPE NCC database support staff. Note that the content of the workshop is distinct from that of the Database WG meeting. The workshop will be of a tutorial nature describing how to work with the new database features. Priorities for further developments will be addressed in the WG as always. REGISTRATION The workshop is open to all members of the RIPE community. Attendees from RIPE NCC contributors will however receive priority. If you plan to attend, please register, using the form at the end of this message, as soon as possible, but before September 16th. This will allow proper planning of workshop logistics. Those who do not register in advance may be turned away if space restrictions arise. Upon completion, send the form should to: <meeting(a)ripe.net> %START PART 1 - Registration %MTG [ dbws1 ] 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton %NAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your e-mail address %EMAIL [ ] 4) Registtry ID The registry ID string of the local IR (if any) e.g. fr.lereseau de.dasnetz uk.thenet. Contributing local IRs will receive priority registration. %REGID [ ] %END

1 0

Newest patches: ripe-dbase.2.0.3 available
by David.Kessens＠ripe.net 19 Aug '96

19 Aug '96

Dear all, The latest release unexpectedly contained a serious flaw in the classless database opening code. The problem was not found before putting things in production due to a non-complete copy of one file into the test database directory (my fault). The new database staff did some emergency measures and consulted me on the phone (The moving company was just packing my computers & modems ;-(). An older version was put back in production which caused the reappearing of some (non fatal) bugs. I want to apologize for the inconvenience this has caused although I hope that you also have some understanding: We were the last three weeks in the inconvenient position that we had to put new code in production while not having the time for an appropriate test period. Postponing the release was not a viable option since I was leaving the RIPE NCC (In fact I already did two weeks ago...), the new people first need some time to get up to speed, and I saw clear signs (in the internals of the database) that we rather should handle fast then slow with introducing the new software. I have prepared a new bug fixed version that also fixes a few other problems (including some older bugs that were already present in the previous release). This version runs now since friday afternoon on our production machine (note the subtle change in the config file: the 'av' attribute added in the 'OBJ an ATSQ' line). The code is available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase.2.0.3.tar.gz Kind regards, David K. ---

1 0

bug fixes & upgraded functionality for 2.0 database release
by David.Kessens＠ripe.net 15 Aug '96

15 Aug '96

Dear all, I have fixed a few small bugs. I also added functionality for automatically adding the current date to the last 'changed:' attribute field in your update when no date is present. Apply the included patches or get a new distribution from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.0.2.tar.gz Kind regards, David K. --- *** encmp.old Wed Aug 14 17:38:53 1996 --- encmp.pl Wed Aug 14 17:45:34 1996 *************** *** 1,9 **** # encmp - compare two associative arrays # # $RCSfile: encmp.pl,v $ ! # $Revision: 2.0 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/08 10:47:30 $ # # This routine takes two objects and compares them case insensitive # Returns 1 if objects are equal, else returns 0; --- 1,11 ---- + # encmp - compare two associative arrays + # 'syntax sugar' is removed before comparing! # # $RCSfile: encmp.pl,v $ ! # $Revision: 2.1 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/14 15:45:19 $ # # This routine takes two objects and compares them case insensitive # Returns 1 if objects are equal, else returns 0; *************** *** 88,103 **** # we do a compare after the syntactic sugar has been removed. if ($key eq "ae") { ! $a=~ s/(^|\n)exclude\s+(AS\d+)\s+to\s+/$1$2 /g; ! $b=~ s/(^|\n)exclude\s+(AS\d+)\s+to\s+/$1$2 /g; } elsif ($key eq "ai") { ! $a=~ s/(^|\n)from\s+(AS\d+\s+\d+)\s+accept\s+/$1$2 /g; ! $b=~ s/(^|\n)from\s+(AS\d+\s+\d+)\s+accept\s+/$1$2 /g; } elsif ($key eq "ao") { ! $a=~ s/(^|\n)to\s+(AS\d+)\s+announce\s+/$1$2 /g; ! $b=~ s/(^|\n)to\s+(AS\d+)\s+announce\s+/$1$2 /g; } elsif ($key eq "it") { $a=~ s/(^|\n)from\s+($match)\s+($\s*pref[\=\s\S]+$)?accept\s+/$1$2 $3/go; --- 90,105 ---- # we do a compare after the syntactic sugar has been removed. if ($key eq "ae") { ! $a=~ s/(^|\n)exclude\s+(as\d+)\s+to\s+/$1$2 /g; ! $b=~ s/(^|\n)exclude\s+(as\d+)\s+to\s+/$1$2 /g; } elsif ($key eq "ai") { ! $a=~ s/(^|\n)from\s+(as\d+\s+\d+)\s+accept\s+/$1$2 /g; ! $b=~ s/(^|\n)from\s+(as\d+\s+\d+)\s+accept\s+/$1$2 /g; } elsif ($key eq "ao") { ! $a=~ s/(^|\n)to\s+(as\d+)\s+announce\s+/$1$2 /g; ! $b=~ s/(^|\n)to\s+(as\d+)\s+announce\s+/$1$2 /g; } elsif ($key eq "it") { $a=~ s/(^|\n)from\s+($match)\s+($\s*pref[\=\s\S]+$)?accept\s+/$1$2 $3/go; *************** *** 117,119 **** --- 119,122 ---- } 1; + *** syntax.old Wed Aug 14 17:39:05 1996 --- syntax.pl Wed Aug 14 17:45:59 1996 *************** *** 1,8 **** ! # # $RCSfile: syntax.pl,v $ ! # $Revision: 2.2 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/09 12:55:04 $ # # ARGUMENTS: *ASSOC object # RETURNS: INTEGER object_status --- 1,8 ---- ! # $RCSfile: syntax.pl,v $ ! # $Revision: 2.3 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/14 15:45:49 $ # # ARGUMENTS: *ASSOC object # RETURNS: INTEGER object_status *************** *** 311,317 **** # } else { ! if ($itmp=~ /^ac|ah|tc|zc|cy|mb|ml$/) { local($val, $msg) = &dosyntax($itmp, $object{$itmp}, *object); # print STDERR "checksyntax - before attr: $itmp rtcode: $rtcode val: $val msg: $msg\n" if ($opt_V); if (defined($val)) { --- 311,317 ---- # } else { ! if ($itmp=~ /^ac|ah|ch|tc|zc|cy|mb|ml$/) { local($val, $msg) = &dosyntax($itmp, $object{$itmp}, *object); # print STDERR "checksyntax - before attr: $itmp rtcode: $rtcode val: $val msg: $msg\n" if ($opt_V); if (defined($val)) { *************** *** 711,759 **** # Try to do something clever with the changed field # # ch - changed # ! if ($key eq "ch") { ! print STDERR "dosyntax - checking ch\n" if $opt_V; ! local($date)=""; ! if ($value=~ / /) { ! $value=~ s/ +(\S+)$//; ! $date=$1; ! } ! # print STDERR "*", $date, "*", $value, "\n"; ! if (!(&isemail($value))) { ! return $O_ERROR, "syntax error in e-mail part of \"$ATTL{$key}\""; } ! if (!$date) { ! return $O_ERROR, ! "No date specified in \"$ATTL{$key}\" attribute"; ! } ! if ($date!~ /^(\d\d)(\d\d)(\d\d)$/) { ! return $O_ERROR, "date part of \"$ATTL{$key}\" not in YYMMDD format"; ! } ! # 1988 is the start of the world. This is where we test for proper ! # date values of YYMMDD ! if (($1 < 88) || ($2 > 12) || ($3 > 31)) { ! return $O_ERROR, "date part of \"$ATTL{$key}\" is not a valid YYMMDD value"; ! } ! if ($date>$DATE) { ! $object{$key} =~ s/$date/$DATE/g; ! return $O_WARNING, ! "date in \"$ATTL{$key}\" ($date) is in the ". ! "future - changed to $DATE"; ! } ! $object{$key}=~ s/ +/ /g; - return $O_OK; - } # --- 711,804 ---- # Try to do something clever with the changed field # # ch - changed + # wd - withdrawn # ! if ($key=~ /^ch|wd$/) { ! print STDERR "dosyntax - checking ch,wd ($key)\n" if $opt_V; ! local($returncode)=$O_OK; ! local($date); ! local(@newchanged)=(); ! local(@changedvalues)=split(/\n+/, $value); ! # ! # add current date if needed to last specified attribute ! if ($changedvalues[$#changedvalues]!~ / \d{6,6}$/) { ! ! $changedvalues[$#changedvalues].=" ".$DATE; ! ! &addwarning(*object, "added current date to ".$ATTL{$key}." field"); ! ! $returncode=$O_WARNING; ! } + + # + # sort values on date + + @changedvalues=sort sortchangedfield @changedvalues; + + #print STDERR join("\n", "values:", @changedvalues); + + foreach $value (@changedvalues) { + + $date=""; + + if ($value=~ / /) { + $value=~ s/ +(\S+)$//; + $date=$1; + } + + # print STDERR "*", $date, "*", $value, "\n"; + + if (!(&isemail($value))) { + return $O_ERROR, "syntax error in e-mail part of \"$ATTL{$key}\""; + } ! if (!$date) { ! return $O_ERROR, "No date specified in \"$ATTL{$key}\" attribute"; ! } ! ! if ($date=~ /^(\d\d)(\d\d)(\d\d)$/) { ! ! # ! # 1988 is the start of the world. This is where we test for proper ! # date values of YYMMDD ! if ($1<88) { ! return $O_ERROR, "date ($date) part of \"$ATTL{$key}\" is older then the database itself!"; ! } ! ! if (($2<1) || ($2>12) || ($3>31) || ($3<1)) { ! return $O_ERROR, "date ($date) part of \"$ATTL{$key}\" is not a valid YYMMDD value"; ! } ! ! } ! else { ! ! return $O_ERROR, "date part of \"$ATTL{$key}\" not in YYMMDD format"; ! } ! ! if ($date>$DATE) { ! ! &addwarning(*object, "date in \"$ATTL{$key}\" ($date) is in the future - changed to $DATE"); ! $date=$DATE; ! $returncode=$O_WARNING; ! ! } ! ! push(@newchanged, $value." ".$date); ! } ! ! $object{$key}=join("\n", @newchanged); ! ! return $returncode; } # *************** *** 1752,1758 **** # # check if the ID is not already used ! return $O_ERROR, "error in \"$ATTL{$key}\", auto NIC handle assignment\nidentification code ($1.$2) already used in other object" if ($NICID{$object{"so"}, $1.$2}); # # find initials if not already specified --- 1797,1803 ---- # # check if the ID is not already used ! return $O_ERROR, "error in \"$ATTL{$key}\", auto NIC handle assignment\nidentification code ($1.$2) already used in other object" if ($NICID{$object{"so"}, $prefix}); # # find initials if not already specified *************** *** 1768,1776 **** $object{$key}=$prefix.$initials; $prefix=~ /\-(\d+)$/; - $NICID{$object{"so"}, $1}=1; return $O_OK; } --- 1813,1827 ---- $object{$key}=$prefix.$initials; + # + # check if the ID is not already used + $prefix=~ /\-(\d+)$/; + return $O_ERROR, "error in \"$ATTL{$key}\", auto NIC handle assignment identification code ($1) already used in other object\nplease use another number then $1" if ($NICID{$object{"so"}, $prefix}); + + $NICID{$object{"so"}, $prefix}=1; + return $O_OK; } *************** *** 2170,2204 **** return $O_OK; } - - # - # wd - withdrawn - # - if ($key eq "wd") { - - print STDERR "dosyntax - checking wd ($key)\n" if $opt_V; - - if ($value !~ /^(\d\d)(\d\d)(\d\d)$/) { - return $O_ERROR, - "date part of \"$ATTL{$key}\" not in YYMMDD format"; - } - - # 1988 is the start of the world. This is where we test for proper - # date values of YYMMDD - - if (($1 < 88) || ($2 > 12) || ($3 > 31)) { - return $O_ERROR, - "date part of \"$ATTL{$key}\" is not a valid YYMMDD value"; - } - - if ($value gt $DATE) { - return $O_ERROR, - "date in \"$ATTL{$key}\" ($1$2$3) is in the future"; - } - - return $O_OK; - } - # # These are not checked and not used, just in here for clarity # --- 2221,2226 ---- *** misc.old Wed Aug 14 17:38:41 1996 --- misc.pl Wed Aug 14 17:46:14 1996 *************** *** 2,13 **** # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 2.0 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/08 10:47:30 $ # require "defines.pl"; sub ReplaceGlobalVars { local(*text)=@_; --- 2,45 ---- # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 2.1 $ # $Author: ripe-dbm $ ! # $Date: 1996/08/14 15:46:06 $ # require "defines.pl"; + + sub sortchangedfield { + + $a=~ /(\d{6,6})$/; + local($date1)=$1; + + $b=~ /(\d{6,6})$/; + + # print STDERR "-$a-$b-$date1-$1-\n"; + + if ((!$date1) && (!$1)) { + + return 0; + + } + elsif (!$date1) { + + return -1; + + } + elsif (!$1) { + + return 1; + + } + else { + + return $date1 <=> $1; + + } + + } sub ReplaceGlobalVars { local(*text)=@_;

2 1

bug fix for 2.00 release
by RIPE Database Manager 10 Aug '96

10 Aug '96

Dear all, I found this morning a bug that could case the software not to remove the lockfile when doing a database cleanup when indexing files with a full path name. Please substitute your 'donetdbm.pl' file by the included one or pick up a new distribution from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.0.1.tar.gz Kind regards, David K. -------- # $RCSfile: donetdbm.pl,v $ # $Revision: 2.1 $ # $Author: david $ # $Date: 1996/08/10 15:53:32 $ require "defines.pl"; require "dbopen.pl"; require "dbclose.pl"; require "enread.pl"; require "enwrite.pl"; require "addkey.pl"; require "enkeys.pl"; require "enukey.pl"; # # exit cleanly when asked to ... sub quitdonetdbm { unlink(@DONETDBMFILES); print "\n$PROGRAMNAME terminated by signal.\n"; exit; } sub flushkeys { local(*database, *normalkeys)=@_; # print STDERR "do flush to disk for normal keys (happens every $MAXLISTLENGTH keys) ..."; local($oldoffsets,$key,$value,$length); # # old overflow files local(@toobig)=(); # # new overflow files local(@toobignewkeys)=(); local(@toobignewvalues)=(); # # normal keys local(@addkeys)=(); local(@addvalues)=(); while (($key,$value)=each(%normalkeys)) { $length=length($key); $key=~ s/^.{$OVERFLOWSIZE-1,$OVERFLOWSIZE-1}.*$/$1/ if ($length>=$OVERFLOWSIZE); # # check if the key already existed, that makes life # more complicated if (($oldoffsets=$database{$key})) { # # add to overflow file if ($oldoffsets=~ s/^$OVERFLOWPREFIXREGULAR//o) { push(@toobig, $oldoffsets, $value); next; } $value=join("\,", $oldoffsets, $value); } # # do a value addition $length+=length($value); if ($length>=$OVERFLOWSIZE) { push(@toobignewkeys, $key); push(@toobignewvalues, $value); } else { push(@addkeys, $key); push(@addvalues, $value); } } # # clean up the memory %normalkeys=(); # # add data to old overflow files local($dbfile)=$database[1].$OVERFLOWEXTENSION; if (@toobig) { while (@toobig) { if (open(OVERFLOWADD, ">>".$dbfile.shift(@toobig))) { print OVERFLOWADD "\,", shift(@toobig); close(OVERFLOWADD); } else { &fatalerror("in donetdbm flushkeys: cannot open for addition $dbfile.$_ value: ".shift(@toobig)." code: $!"); } } } # # create new overflow files if (@toobignewkeys) { local($filenumber)=$database{$OVERFLOWKEY}; local(@overflowvalues)=(++$filenumber .. ($filenumber+scalar(@toobignewkeys)-1)); push(@addkeys, $OVERFLOWKEY); push(@addvalues, $overflowvalues[$#overflowvalues]); #print STDERR join(" ", @toobignewkeys), "\n"; #print STDERR join(" ", @toobignewvalues), "\n"; #print STDERR join(" ", @overflowvalues), "\n"; foreach (@overflowvalues) { if (open(OVERFLOWNEW, ">".$dbfile.$_)) { print OVERFLOWNEW shift(@toobignewvalues); close(OVERFLOWNEW); } else { &fatalerror("in donetdbm flushkeys: cannot open for creation $dbfile.$_ value: ".shift(@toobignewvalues)." code: $!"); } } push(@addkeys, @toobignewkeys); push(@addvalues, (@overflowvalues=grep($_=$OVERFLOWPREFIX.$_, @overflowvalues))); } # # add all keys to the physical database in one single command !!! @database{@addkeys}=@addvalues; # print STDERR " done\n"; return 0; } sub flushclkeys { local($basename, $i, *list, *notexistingprefixes)=@_; #print STDERR "do flush to disk prefix \/$i (happens every $MAXSTRINGCOMPONENTS prefixes) ..."; local($file)=$basename.$i; push(@DONETDBMFILES, $file) if (grep($_ ne $file, @DONETDBMFILES)==scalar(@DONETDBMFILES)); open(FLUSHCLKEYS, ">>".$file); print FLUSHCLKEYS $list[$i]; close(FLUSHCLKEYS); #print STDERR " done\n"; $list[$i]=""; $notexistingprefixes[$i]=0; return 0; } sub donetdbm { local($filename, $todir, $options)=@_; local($type,$uniquekey,$offset,$prefix); local($NEWDIR, $newfilename); local($classless)=$options & $CLASSLESSOPTION; local($cleaning)=$options & $CLEANOPTION; local(%entry); local($objseen) = 0; local($processed)=0; local(@clalist)=(); local(@classlesslist)=(); local(@nrofentries)=(); local(%normalkeys)=(); local(@notexistingprefixes)=(1) x 129; local(@keys,@otherkeys,@pointsto,@otherpointsto,@classless); local($basename); local($newdb)='newdb'; local(%newdb,@newdb); local(%nothing)=(); local($lockfile); # print STDERR "donetdbm - file: $filename classless: $classless cleaning: $cleaning\n"; if ($cleaning) { ($NEWDIR, $newfilename)= $filename=~ /$SPLITFILENAME/o; $lockfile=$CLEANLOCK.$newfilename; # We will create a temporary directory to build the new database and # indexes. $NEWDIR.=$newfilename."-newindex.".$$; $newfilename=$NEWDIR."\/".$newfilename; &fatalerror("Temporary directory \"$NEWDIR\" already exists!") if (-d $NEWDIR); if (!mkdir($NEWDIR, 0750)) { &fatalerror("Failed to create temporary directory ($!): $NEWDIR"); } &dbopen(*newdb, *nothing, 1, $newfilename ) || &fatalerror("Cannot open $newfilename"); seek($newdb,0,2); } else { &delormoveindices($filename, "", $classless); } local(%dummyobject)=(); local($db)='db'; local(%db,@db); &dbopen(*db,*dummyobject,1,$filename) || &fatalerror("$0: error opening database: $filename"); seek($db,0,0); if ($cleaning) { &fatalerror("lockfile: $lockfile already exists") if (-e $lockfile); push(@DONETDBMFILES, $lockfile); open(LOCKFILE, ">".$lockfile) || &fatalerror("cannot create $lockfile"); print LOCKFILE "$$\n"; close(LOCKFILE); } if ($classless) { local($prefixfilename); if ($filename=~ /^.*\/([^\s\/]+)\s*$/) { $prefixfilename=$2; } else { $prefixfilename=$filename; } $basename=$TMPDIR."/prefixdata.".$$.".".$prefixfilename; # # remove any possible left over files... local(@files)=(); for $i (0..128) { push(@files, $basename.$i) if (-f $basename.$i); } unlink(@files) if (@files); } # # exit clean on a signal (except for the cleaning files, I am sorry # no time for the real fancy stuff) $SIG{'INT'}='quitdonetdbm'; $SIG{'KILL'}='quitdonetdbm'; $SIG{'TERM'}='quitdonetdbm'; @OPENNETDBMFILES=(); # # start gathering the keys... while ($type=&enread($db, *entry, -1)) { next if (!$OBJATSQ{$type}); # print STDERR "type: $type\n"; # $objseen++; # if ($objseen % 400 == 0) { # print STDERR "donetdbm - indexed $objseen\n"; # } # print STDERR "entry ($type): ", $entry{$type}, "\n"; # print STDERR "\noffset: ", $entry{"offset"}; # print STDERR "\nuniquekey: $uniquekey\n"; if ($cleaning) { $offset=&enwrite($newdb,*entry); } else { $offset=$entry{"offset"}; } &enkeys(*entry, $OBJKEYS{$type}, *keys, *otherkeys, *pointsto, *otherpointsto, *classless, $classless); $processed+=grep((($normalkeys{$_}) && ($normalkeys{$_}=join("\,", $normalkeys{$_}, $offset))) || ($normalkeys{$_}=$offset), ($uniquekey=&enukey(*entry, $type)), @keys, @otherkeys, @pointsto, @otherpointsto); if ($cleaning) { $processed=&flushkeys(*newdb, *normalkeys) if ($processed>$MAXLISTLENGTH); } else { $processed=&flushkeys(*db, *normalkeys) if ($processed>$MAXLISTLENGTH); } if ($classless) { foreach (@classless) { /^(.+)\/(\d+)$/; $classlesslist[$2]=join("", $classlesslist[$2], $1, "\%", $uniquekey, "\%"); $nrofentries[$2]=&flushclkeys($basename,$2,*classlesslist,*notexistingprefixes) if (++$nrofentries[$2]>$MAXSTRINGCOMPONENTS); } } } # # note: we do the wait for a child flush *after* the classless indexing # it might save us some extra time! if ($cleaning) { &flushkeys(*newdb, *normalkeys); } else { &flushkeys(*db, *normalkeys); } # # now we start with the classless indices if ($classless) { undef %normalkeys; print STDERR "docldbm - start inserting prefixes\n" if $opt_V; if ($cleaning) { &dbclopen(*dummyobject,1,$newfilename); } else { &delormoveindices($filename.$CLASSLESSEXT, "", $classless); &dbclopen(*dummyobject,1,$filename); } $objseen = 0; local($entry); local($p,$i,$cla,$newcla); # # we need to read entries separated by '%' characters # # trickey: we don't need to reset it for: # # flushclkeys, getvalues, addkey since # they are not affected. local($/)="\%"; for $i (1..128) { print STDERR "try $basename$i\n" if ($opt_V); # # flush first the remaining prefixes... &flushclkeys($basename, $i, *classlesslist, *notexistingprefixes) if ($nrofentries[$i]); next if ($notexistingprefixes[$i]); undef $nrofentries[$i]; if (open(FLUSHCLKEYS, "<".$basename.$i)) { print STDERR "opened $basename$i\n" if ($opt_V); $entry=1; while ($entry) { print STDERR "read from $basename$i\n" if ($opt_V); $processed=0; undef @clalist; while (($processed<$MAXLISTLENGTH) && ($entry=<FLUSHCLKEYS>)) { $key=<FLUSHCLKEYS>; chop($entry); chop($key); push(@clalist,$entry,$key); $processed++; } while ($prefix=shift(@clalist)) { # print STDERR $prefix, "\n"; if (&addkey(*mspnxl, ($cla=join("\/", $prefix, $i)), shift(@clalist))) { for ($p=$i-1; ($p>0) && (($notexistingprefixes[$p]) || (!defined($mspnxl{($newcla=join("\/", &iprightzeromask($prefix,$p), $p))}))); $p--) {}; # print STDERR $p, " ",$i, " ", $newcla, "\n"; &addkey(*mspnxl, $p>0?$newcla:"0\/0", $cla); } } } close(FLUSHCLKEYS); push(@DONETDBMFILES, $basename.$i); } else { &fatalerror("Couldn\'t open prefix file: $basename$i ($!)"); } } unlink(@DONETDBMFILES) if (@DONETDBMFILES); # # make the not existing prefixes array $mspnxl{$NOTEXISTINGPREFIXESKEY}=join(" ", @notexistingprefixes); &dbclclose(); } # # we might still have a child process for the normal keys... # wait; # print STDERR "closing\n"; if ($todir) { ($NEWDIR, $newfilename)= $filename=~ /$SPLITFILENAME/o; $lockfile=$CLEANLOCK.$newfilename; &fatalerror("lockfile: $lockfile already exists") if (-e $lockfile); # # we don't accept termination of the program from here @DONETDBMFILES=(); $SIG{'INT'}='IGNORE'; $SIG{'KILL'}='IGNORE'; $SIG{'TERM'}='IGNORE'; open(LOCKFILE, ">".$lockfile) || &fatalerror("cannot create $lockfile"); print LOCKFILE "$$\n"; close(LOCKFILE); $todir.="\/" if ($todir!~ /\/\s*$/); &dbclose(*db); &delormoveindices($filename.$CLASSLESSEXT, $todir.$newfilename.$CLASSLESSEXT, $classless) if ($classless); &delormoveindices($filename, $todir.$newfilename, 0); unlink($lockfile); } elsif ($cleaning) { &dbclose(*newdb); &dbclose(*db); # # we don't accept termination of the program from here @DONETDBMFILES=(); $SIG{'INT'}='IGNORE'; $SIG{'KILL'}='IGNORE'; $SIG{'TERM'}='IGNORE'; &delormoveindices($newfilename.$CLASSLESSEXT, $filename.$CLASSLESSEXT, $classless) if ($classless); &delormoveindices($newfilename, $filename, 0); unlink($lockfile); warn "could\'t remove directory ($NEWDIR) errorcode: $!\n" if (!rmdir($NEWDIR)); } else { # print STDERR "close db\n"; &dbclose(*db); # print STDERR "done db\n"; } # print STDERR "done -$/- db\n"; return; #print STDERR "done db\n"; } 1; --------

1 0

Announcement: Release of RIPE datase software 2.00
by RIPE Database Manager 09 Aug '96

09 Aug '96

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 previous beta release. The software is available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.00.tar.gz The following lists the most interesting new features since the previous non-beta release (you can do 'whois -h whois.ripe.net HELP' to get the RIPE database HOWTO that includes more detailed information on the new features): - AUTO NIC handle assignment support. The (slow) finger tool is not needed any more (see the HOWTO for more details on how to use this new feature). - hierarchical authorization for creation of 'inetnum' and 'domain' objects. Use a 'mnt-lower: YOUR-MAINTAINER' attribute for these objects to use the authorization of YOUR-MAINTAINER for the creation of objects direct below in the hierarchy your object with the 'mnt-lower:' line. - role object support. Get a template by doing 'whois -h whois.ripe.net -t role'. All attributes are already known, except for the 'trouble:' attribute that can contain any free text. Note: references to the role object may not be used in the 'admin-c:' attribute, however the use of the object in 'tech-c:' & 'zone-c:' is fine. - prefix notation for 'inetnum:' updates & classless range support for whois lookups - extended 'country:' attribute syntax implemented, more then one country 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 currently only 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 (-c option) and automatically detects if it is dealing with a classless index. netdbm & cleandb are now obsoleted. Indexing speed has been improved by a factor of at least two on average although the number of indexed values is more then twice the previous number. RAM memory consumption is also limited to about 6 Mb depending on your architecture. - reverse lookup of objects (whois -i option), this enables you to find for example the routes with a given origin 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! Note: this is not an approved object whatsoever. It is intended for testing ipv6 indexing but can serve as a good starting point for further discussion. Get a template by doing: 'whois -h whois.ripe.net -t inet6num' 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 new job at ISI very soon. And finally: Thanks for all your help, patience with bugs, bug reports and patches! Kind regards, David K. --- ***Warning*** for upgraders: A reindex (indexdb -c -s SOURCE) is necessary since the internal index formats changed! RELEASE NOTES (RIPE database version 2.00): - AUTO NIC handle assignment support. The (slow) finger tool is not needed any more (see the HOWTO for more details on how to use this new feature). Gabor Kiss provided be with some very usefull patches for part of the work. - hierarchical authorization for creation of 'inetnum' and 'domain' objects. Use a 'mnt-lower: YOUR-MAINTAINER' attribute for these objects to use the authorization of YOUR-MAINTAINER for the creation of objects direct below in the hierarchy your object with the 'mnt-lower:' line. - role object support. Get a template by doing 'whois -h whois.ripe.net -t role'. All attributes are already known, except for the 'trouble:' attribute that can contain any free text. Note: references to the role object should and may not be used in the 'admin-c:' attribute, however the use of the object in 'tech-c:' & 'zone-c:' is fine. - 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 (-c option) 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 choosen 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 & whois lookups - 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 is available from ftp://ftp.ripe.net/tools/perl4.036-for-solaris.tar.gz. Peter Haag has made the perl version and patches available to me. Thanks! 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 - the list of current proposals (soon to be reposted to the <db-wg(a)ripe.net> maillist.

1 0

HELP! finger handle... out of order
by hostmaster＠xlink.net 09 Aug '96

09 Aug '96

Hello, please give me the chance again, to get RIPE-Handles for person via the finger- or an other service. We use RIPE-Handles in our internal customer-database, the use of AUTO-Handle needs a rewriting of several tools, if possible at all. At the ripe-meeting in Berlin, it was said, that the auto-assign will be an _addional_ feature. Yours, Wilhelm -- Wilhelm Buehler email: 'see reply-to:' NTG Netzwerk und Telematic GmbH / fax: +49 721 9652 210 Geschaeftsbereich Xlink \/ phone: +49 721 9652 211 Vincenz-Priessnitz-Str. 3 /\ link http://www.xlink.net/~wb/ D-76131 Karlsruhe, Germany /_______ Freiheit verbindet. Weltweit.

2 2

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