- db-wg - mailman.ripe.net

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

15 Jul '96

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

2 1

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

15 Jul '96

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

1 0

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

15 Jul '96

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

4 3

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

11 Jul '96

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

1 0

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

11 Jul '96

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

1 0

FYI: new 2.00 whois server runs now on port 4444
by David.Kessens＠ripe.net 28 Jun '96

28 Jun '96

Dear all, The new 2.0 whois server runs now on port 4444. People might want to give it a try before we put it in production. New features: - twice the speed for any classless lookups - the lookup algoritm is changed such that: Matyas Matyas can finally be found and also Daniel David hasn't problems anymore with finding himself in the database - unlimited number of matches allowed you can now find all davids in the RIPE database As always: please send bug reports directly to me and I will fix the problem. The service will be a little bit less reliable then our standard whois server since I am still working on the code. In general: I will try to keep the new server only 5 seconds behind the normal server between 9:00-19:00 local time. We will put the server in production when I have finished the code for the role object and auto NIC handle generation. I plan to finish that in about a week time. Kind regards, David K. --- How to try this out: Do the next command if your whois client supports choosing different ports then the default one (or edit the RIPE perl whois source code) $ whois -p 4444 -h whois.ripe.net Matyas Matyas Or do: $ telnet whois.ripe.net 4444 <return> Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. Matyas Matyas <return> (The new database distribution will include a whois version that supports the selection of the port)

4 6

problem installing the RAToolset v.3.3.2 on OSF/1
by Claudia Battista - INFN Roma 24 Jun '96

24 Jun '96

I received an "user unknown at ISU.EDU" error message from my postmaster sending the following mail to: rps(a)isi.edu or cengiz(a)isu.edu. Can you help me? I ask you because in the original mail announcing the new tools your e-mail was in the "comments to" field (see at end of the mail I included) Thank you in advance Claudia Battista INFN - Roma ==================================================================== My mail to Cengiz ==================================================================== Hi Cengiz, I am trying to install the whole tool set RAToolSet v.3.3.2 on a DEC alpha station 3000/600 running OSF/1 3.2B. The enviroment requirements are satisfied (g++ 2.7.2, Tk 4.0 Tcl 7.4....) but any effort to compile it by means of makefiles was completely unseccesfull. I think that it depends on some option or definition in the makefiles which is not compatible with the OSF/1 'make' tool. Have you experience other than in a SunOS enviroment? Thank you in advance. Claudia Battista Istituto Nazionale Fisica Nucleare Sezione di Roma ==================================================================== Original mail from Cengiz ============================================================= Sender: <ROUTING(a)nis.garr.it> (ROUTING Coordinamento routing GARR) From: <cengiz(a)ISI.EDU> (Cengiz Alaettinoglu) To: <ROUTING(a)GARR.it> (Multiple recipients of list ROUTING) Subject: Route Object Editor: New tool ....... Comments: To: rps(a)ISI.EDU, db-wg(a)ripe.net Hi, A new tool, roe (route object editor), is available: DESCRIPTION roe is a Tcl/Tk program that lists the routes registered by an AS. roe can be used to find discrepancies between the registered routes and the routes that are actually being routed. roe can be used to find all the holes that are punched in the AS's routes, or all the holes the AS punches in other routes. roe can be used to easily add, delete and update route objects in any IRR registry (hence the name editor). For example, one can register all the routes which are routed but not registered in couple of mouse clicks. It is part of RAToolSet v 3.3.2 and is available at: http://www.isi.edu/~cengiz/software Your feedback and bug reports are greatly appreciated. Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz ====================================================================

2 1

Re: FYI: List of current proposals
by martin＠terena.nl 24 Jun '96

24 Jun '96

At 6:05 PM 6/18/96, David.Kessens(a)ripe.net wrote: >You can find a more detailed description below. Please let me know if you >know of any other proposals that I forgot about, Are these items in order of priority? (Sorry if i've missed something...) Anyway, congratulations on the job and good luck for the future. Regards, John

2 1

subscribe
by Edouard Ouin 21 Jun '96

21 Jun '96

subscribe me email = edouard.ouin(a)inria.fr -- Edouard OUIN E-Mail: Edouard.Ouin(a)inria.fr Tel: 39.63.50.56 Fax: 39.63.55.34 NIC France E-Mail: nic(a)nic.fr INRIA-Rocquencourt Domaine de Voluceau B.P. 105 78153 Le Chesnay Cedex http://www.nic.fr/~ouin

1 0

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 21 Jun '96

21 Jun '96

Hi Blasco ! => Thus we have been looking into alternatives and ways of tricking the => web browser into doing things that it wasn't meant for :-) = =Maybe I've lost the point in this discussion but.. I think so. And it was entirely my fault to re-hash this stuff on the db-wg list. Just because I got a useful hint to something that was used already, I copied the list - under the assumption that it might be useful for others as well. Obviously I simply added to the confusion. Apologies. 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

URGENT: database ftp mirror problems and changes on the ftp site
by David.Kessens＠ripe.net 21 Jun '96

21 Jun '96

Dear all, We had this morning troubles with copying our database files to the ftp site for people that run a secondary mirror. The problems are solved right now. However, I needed to make some changes in the procedures that affect all people that use our non 'gzipped' files. Since I wanted to make these changes anyway, I want to ask you if they are acceptable for you: I only make the 'gzipped' files available from now on. This causes less confusion between the different files available, less network traffic, faster availability of the database files on the ftp server and less load on the database server. Please let me know if you really need the uncompressed or .Z compressed files available and I will change this back. If you have any further questions, please don't hesitate to contact me again, Kind regards, David Kessens RIPE NCC

1 0

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 21 Jun '96

21 Jun '96

Hi Peter ! => lookup key. On the other hand I haven't had enough time and expertise => to try to teach a browser about something like => => whois://db-server-FQDN:43/lookup-key = =To my knowledge there are no whois-URLs yet, but you can (ab-)use =gopher-URLs to watch Whois-Entries with your web-browser. =Give it a try with <gopher://whois.ripe.net:43/0WW144> We actually use it in some situations, but there are two major problems involved: - this does no longer work for Netscape V2.x on Windows PCs (while it does work on Unix boxes and V1.x an the PC was fine ;-) - and I think (for good reasons!) the RIPE-NCC is about to discontinue the gopher access to the whois database. It's a fairly limited approach anyway. Thus we have been looking into alternatives and ways of tricking the web browser into doing things that it wasn't meant for :-) Cheers, Wilfried.

3 2

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 20 Jun '96

20 Jun '96

=> The basic obstacle that stopped me to make any progress is to find a => way (protocol, port, lookup key transfer mechanism) to query the db and => then to convince the browser to read the text as html. The best I => managed was gopher and interpretation as text. => Not that useful in the end... = =I want to do the following (as dicussed with you earlier in a private =conversation): = =Make a 'whois -w' that let the whois program behave as cgi-bin script: = =The whois server will return you an html formatted document instead of =regular plain text objects. It's then very easy to put such a 'whois' =program in your cgi-bin directory and here you go... The nice thing about =this the unified presentation of objects in a web based context. =Furthermore, people can use url's to specified objects in the database. Do I read this correctly to expect me (the users wanting access) to install some cgi script on the/a local server to provide that interface? That might drastically limit the usefulness of this approach. I'd prefer something that is more along the lines of the good old to be retired gopher interface - I'd like to give a special port number and have the script run at the whois DB server side. I think we do have all the building blocks in place (like telnet to 43), but this breaks 'cause a telnet opens a separate window from the browser and fails to submit the rest of the url to be treated as a lookup key. On the other hand I haven't had enough time and expertise to try to teach a browser about something like whois://db-server-FQDN:43/lookup-key >Example: > >An html document about the escalation procedures for network outages of >an ISP can point directly to a 'role:' object in the RIPE database. That's exactly one of the applications for that approach. Another one would be to have a domain object point to the URL for the application template. And another one would be to do a "whois help" to give access to documentation. And another to reference person objects for people being regularly updated in the DB... >Shall I add such a feature to my proposal list in addition to the WAIS >interface (with a note that the WAIS interface can be enabled quickly >with some hacks as proposed by Blasco) ? My private opinion is: YES. My DB-WG opinion is: probably, but we didn't have it on the agenda - thus as a proposal for future decision 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 --------------------------------------------------------------------------

3 2

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 20 Jun '96

20 Jun '96

Hi David ! => => What about the WWW/WAIS interface to the database? = =I will add it to the list. It probably slipped my mind (by my software =engineer perspective) since it is not part of the database software =itself, but a separate project. = =As far as me concerned, it is a very useful addition to the database =interfaces we already have and thus should be high on our priority list =(for the new website). I think that's 2 different issues: - WWW/WAIS access to the information contained in the DB That's probably a separate project that might need some finishing touches from the DB software engineer(s) - WWW/HTML/HTTP functionality in the DB-SW package and the whois-server and whois-client That's from my point of view part of the item to include/provide means to register URLs (in some way or another) in the DB objects. But registering the URL strings itself is not a major problem (we could use a remarks field for that porpose as an interim measure - look at spt1-ripe :-), but the *access* to the objects by way of an http or whois interface is! I haven't found a trick yet to make my browser process an object as html code... For the moment I'd like to concentrate my efforts on the second aspect! David, is there a chance to meet you during the IETF to share some drinks and thoughts? Wilfried.

4 3

Re: FYI: List of current proposals
by David.Kessens＠ripe.net 20 Jun '96

20 Jun '96

Dear Wilfried, Blasco, > Wilfried Woeber, UniVie/ACOnet writes : > > Hi Blasco ! > > => - WWW/HTML/HTTP functionality in the DB-SW package and the whois-server > => and whois-client > => > => That's from my point of view part of the item to include/provide > => means to register URLs (in some way or another) in the DB objects. > => But registering the URL strings itself is not a major problem (we > => could use a remarks field for that porpose as an interim > => measure - look at spt1-ripe :-), > => but the *access* to the objects by way of an http or whois > => interface is! I haven't found a trick yet to make my browser > => process an object as html code... > = > =It is anyway needed to reformat the DB object in HTML. That is exactly > =what the cgi-bin in our software does. We can cooperate to port > =this part of software in a different context (whois ?). > > How did you solve that? do you use plain vanilla whois towards the DB > and dish out html towards the browser? > > The basic obstacle that stopped me to make any progress is to find a > way (protocol, port, lookup key transfer mechanism) to query the db and > then to convince the browser to read the text as html. The best I > managed was gopher and interpretation as text. > Not that useful in the end... I want to do the following (as dicussed with you earlier in a private conversation): Make a 'whois -w' that let the whois program behave as cgi-bin script: The whois server will return you an html formatted document instead of regular plain text objects. It's then very easy to put such a 'whois' program in your cgi-bin directory and here you go... The nice thing about this the unified presentation of objects in a web based context. Furthermore, people can use url's to specified objects in the database. Example: An html document about the escalation procedures for network outages of an ISP can point directly to a 'role:' object in the RIPE database. Shall I add such a feature to my proposal list in addition to the WAIS interface (with a note that the WAIS interface can be enabled quickly with some hacks as proposed by Blasco) ? David K. ---

1 0

RE: FYI: David K. will be leaving the RIPE NCC
by Wilfried Woeber, UniVie/ACOnet 19 Jun '96

19 Jun '96

Hi David ! >Dear all, > >After working for nearly 2 years at the RIPE NCC, I feel it is time for a >change. I have found a new job at ISI (Los Angeles) where I will be >involved with the RA project. I will leave the RIPE NCC at the end of July. As I said previously in a private message, sometimes it's a pity staying behind at the wrong side of the pond... I don't want to add to Mike's general praise - he has worded it much better than I could. Instead I'd like to extend our thanks to you wearing my hat as the RIPE-DB-WG convenor. It was, and still is, a pleasure to work with you, both professionally and personally. All the best for your new position! I sincerely hope to keep in contact and to continue the successful collaboration as close as possible. Again - both personally and professionally! 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

FYI: David K. will be leaving the RIPE NCC
by David.Kessens＠ripe.net 19 Jun '96

19 Jun '96

Dear all, After working for nearly 2 years at the RIPE NCC, I feel it is time for a change. I have found a new job at ISI (Los Angeles) where I will be involved with the RA project. I will leave the RIPE NCC at the end of July. As for the RIPE database: We currently plan to bring out the long expected 2.00 release version as soon as possible to keep some time left while I am still at the RIPE NCC in case problems arise. You can soon expect a message from me at the database working group maillist with all the open proposals (as promised during the last RIPE meeting). I would like to thank the RIPE community for their support of and input on my development work on the RIPE database and the reverse delegation tool. I hope that I will be able to collaborate as productively with you in my new job as we have in the past. Kind regards, David K. RIPE NCC ----

4 3

FYI: List of current proposals
by David.Kessens＠ripe.net 19 Jun '96

19 Jun '96

Dear all, I have completed the action point of the RIPE database working group to make a list of active proposals. 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 (included in 2.00 release, if the minutes are published) 4) inverse lookup 5) whois -tv 6) referral mechanism 7) INADDR 8) NEW 9) stronger authorization 10) extended as-in 11) stored/processed attribute 12) name tag 13) url attribute 14) syntactic cleanup You can find a more detailed description below. Please let me 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: half way done Time estimation: long, will be included in 2.00 release 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: half way done Time estimation: medium, will be included in 2.00 release 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, will be included in 2.00 release if the database workinggroup minutes are approved in time 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. 4) inverse lookup Current state: No proposal, nothing 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: nothing done Time estimation: short substitute the <auto-assign(a)ripe.net> mail 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 his implementation required certain external tools seems like they have been addressed What is it? See proposal by Cengiz Alaettinoglu <cengiz(a)ISI.EDU> that 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. Therefor 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. ========

2 2

Route Object Editor: New tool
by Cengiz Alaettinoglu 12 Jun '96

12 Jun '96

Hi, A new tool, roe (route object editor), is available: DESCRIPTION roe is a Tcl/Tk program that lists the routes registered by an AS. roe can be used to find discrepancies between the registered routes and the routes that are actually being routed. roe can be used to find all the holes that are punched in the AS's routes, or all the holes the AS punches in other routes. roe can be used to easily add, delete and update route objects in any IRR registry (hence the name editor). For example, one can register all the routes which are routed but not registered in couple of mouse clicks. It is part of RAToolSet v 3.3.2 and is available at: http://www.isi.edu/~cengiz/software Your feedback and bug reports are greatly appreciated. Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

Re: proposed extensions for as-macro, community names
by Wilfried Woeber, UniVie/ACOnet 11 Apr '96

11 Apr '96

=> Some issues which seem to require further discussion: => => <string> length => Should we require the <string> to be more than one character => long? That is, should as-macro names such as "AS-A" be => illegal? If we require more characters, how many more => should we require? Alternatively, we could rely on commun- => ity pressure to discourage meaningless names. Don't put "artificial" requirements into the softwre, please. Though we might eventually agree on some operational rules. => => ending characters => Should we require as-macro names to end in an alphabetic => letter or digit? That is, should names such as "AS-ISP_" be => illegal? Alternatively, we could rely on community pressure => to discourage such apparently badly formed names. => No preference - unless there is a *distinct* advantage in implementation to disallow certain character combinations. => case sensitivity => Should the comparisons of as-macro names be case insensi- => tive? That is, should the database software consider the => as-macro name AS-EBONE to be the same as the as-macro name => as-ebone? = =Pick something and let's move on to real problems. I think the whole package is non case sensitive right now. Any specific reason to change that? I'd prefer to stick with *not* being case sensitive. => [....] = =Same here. = =I'm don't favor syntax checking for asthetically pleasing names, but I =don't plan to use really ugly ones either. Go either way. :-) I agree, don't put "style" into syntax rules... 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

1st draft: proposed agenda - DB-WG at RIPE 24, Berlin
by Wilfried Woeber, UniVie/ACOnet 11 Apr '96

11 Apr '96

This is the 1st proposal of a draft agenda for the Database-WG at RIPE 24 in Berlin. **Message to the NCC WG scheduling department: If at all possible - please have the DB-WG meeting slot(s) scheduled near the end of the WG stream(s). Thank you! Apologies if I missed something obvious... As usual, comments, additions, deletions welcome. See you, Wilfried. PS: Please don't be disappointed if I don't respond for the next few days, I'll be back in the office by Sat.20.4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 24, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - changes since RIPE 23 - experience with new features C. RADBServer report by Gerald Winters (Merit) D. Review of proposed changes in Europe and North America - active proposals - list of activities and/or implementation - priorities and/or resposibilty for development - coordination (if any :-) E. User interfaces - progress with WAIS integration Y. Input from other WGs Z. AOB Draft 1.0, 11-APR-1996, WW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: update: minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by M.H.Behringer＠dante.org.uk 11 Apr '96

11 Apr '96

>From the minutes: At 12:02 pm 21/3/1996, Wilfried Woeber, UniVie/ACOnet wrote: [...] > The Role: or NOC: object needs more thought and detailed definition. > There is still some uncertainty whether a full-blown new object (with a > handle) is really needed, or whether the person object can be extended. > Input was received from Michael H. Behringer that proposed a common > format for describing contact information, coverage and emergency > preocedures. This object is to be re-visited on the mailing list and a > decision about implementation is being sought on the list. [...] >Wilfried Woeber, Michael H. Behringer: To initiated discussion on the > mailing list about the need and possible format for a role: or > noc: object. I sent out mail on this on 8. March 96, proposing to implement the role object in the DB, because I think it is the "clean" way to implement e.g. AS objects with. My mail led to a true storm of follow-up mails; well, maybe not quite, there was one response from Joachim (thanks!). But as this response was definitely positive, I guess we can conclude that we had 100% agreement on this issue. :-) Can we therefore consider this matter decided? Michael

1 0

proposed extensions for as-macro, community names
by Brian Renaud 09 Apr '96

09 Apr '96

Hello all, I've enclosed below a document which proposes changes to the syntax for the as-macro and community names. I invite your comments. -Brian ================================================================= Proposed Modifications to AS Macro and Community Attribute Syntax ABSTRACT This document describes proposed modifications to the syntax of the as-macro and community attributes. This amends the as-macro syntax described in RIPE-181, Appendix C and the community syntax described in RIPE- 181, Appendix B. 1. Introduction Some ISPs would like to use longer names or structured names for their as-macro and community attribute values. They find these names difficult to read when they use only monocase alphabetic letters. (The syntax specified for these attributes in RIPE-181.) The following extensions to the RIPE-181 syntax provide a richer character set for these attributes. 2. AS-Macro Attribute 2.1. Syntax for as-macro Attribute The revised description and syntax for the as-macro is: as-macro: The name of a macro containing at least two Autonomous Sys- tems grouped together for ease of administration. Format: AS-<string> The <string> must satisfy the following constraints: + It must be at least one character long. + It must contain only upper case letters, lower case letters, digits, underscores (_) or dashes (-). + It must start with an upper case letter or a lower case letter. Note that all comparisons will be case insensitive, so that the database software will consider the as-macro "AS-EBONE" to be the same as the as-macro "as-ebone" 2.2. Examples: as-macro: AS-EBONE as-macro: as-ebone as-macro: AS-ISP-Backbone as-macro: AS-WEST_COAST_POP_1 2.3. Discussion Points Some issues which seem to require further discussion: <string> length Should we require the <string> to be more than one character long? That is, should as-macro names such as "AS-A" be illegal? If we require more characters, how many more should we require? Alternatively, we could rely on commun- ity pressure to discourage meaningless names. ending characters Should we require as-macro names to end in an alphabetic letter or digit? That is, should names such as "AS-ISP_" be illegal? Alternatively, we could rely on community pressure to discourage such apparently badly formed names. case sensitivity Should the comparisons of as-macro names be case insensi- tive? That is, should the database software consider the as-macro name AS-EBONE to be the same as the as-macro name as-ebone? 3. Community Attribute 3.1. Syntax for community Attribute The revised description and syntax for the community is: community: The name of the community. The name of the community should be descriptive of the community it describes. Format: <community-name> The <community-name> must satisfy the following con- straints: + It must be at least one character long. + It must contain only upper case letters, lower case letters, digits, underscores (_) or dashes (-). + It must start with an upper case letter or a lower case letter. + 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 pol- icy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) The keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. Note that all comparisons will be case insensitive, so that the database software will consider the community WCW to be the same as the community wcw. 3.2. Examples: community: WCW community: ISP-Transit-1 3.3. Discussion Points Some issues which seem to require further discussion: community name length Should we require the community names to be to be more than one character long? That is, should community names such as "x" be illegal? If we require more characters, how many more should we require? Alternatively, we could rely on community pressure to discourage meaningless names. ending characters Should we require community names to end in an alphabetic letter or digit? That is, should names such as "ISP- Backbone_" be illegal? Alternatively, we could rely on com- munity pressure to discourage such apparently badly formed names. case sensitivity Should the comparisons of community names be case insensi- tive? That is, should the database software consider the community name WCW to be the same as the community name wcw?

2 1

Re: bug in the whois/wais query?
by zsako＠banknet.net 04 Apr '96

04 Apr '96

> From owner-db-wg(a)ripe.net Wed Apr 3 19:00:08 1996 Dear David, > > Janos Zsako writes : > > > > I have noticed a problem with a person called Matyas Matyas. > > I needed him in the RIPE database. I queried the database and got: > > > > whois -h whois.ripe.net "Matyas Matyas" > > person: Dedi Matyas > > address: RADCOM Ltd. > > address: 8 Hanechoshet St. Tel-Aviv 69710, Israel > > phone: +972 3 6472694 > > fax-no: +972 3 6474681 > > e-mail: dedi(a)radcom.co.il > > nic-hdl: DM55-RIPE > > notify: lir(a)NetVision.net.il > > mnt-by: NNCC > > changed: steiff(a)NetVision.net.il 960225 > > source: RIPE > > > > I therefore registered the following person: > > > > person: Matyas Matyas > > address: HotSoft Tirgu Mures - ROMANIA > > address: O.P. 1, C.P. 172 > > address: 4300 Tirgu Mures - Romania > > phone: +40 65 16 65 16 > > fax-no: +40 65 16 62 90 > > e-mail: matyi(a)hotsoft.vsat.ro > > nic-hdl: MM200-RIPE > > notify: ncc(a)banknet.net > > changed: zsako(a)banknet.net 960403 > > source: RIPE > > > > I queried the database in the same way and I got the same result as the first > > time! > > > > Therefore I suspected the person had been registered earlier and I queried > > the database with the WAIS option (through telnet info.ripe.net). > > I looked for the word "Matyas" and I got three results, one of them was the > > object below: > > > > person: Matyas Matyas > > address: HotSoft Tirgu Mures - ROMANIA > > address: O.P. 1, C.P. 172 > > address: 4300 Tirgu Mures - Romania > > phone: +40-65-166516 > > fax-no: +40-65-166290 > > e-mail: matyi(a)hotsoft.vsat.ro > > nic-hdl: MM184-RIPE > > changed: alina(a)u1.ici.ro 960326 > > source: RIPE > > > > and two irrelevant person objects, but the person with the NIC-handle > > MM200-RIPE was not there! > > I got a similar result with a different keyword ("matyi" from the e-mail > > address) and again got MM184-RIPE, but not MM200-RIPE. > > > > Is this normal (did I miss something) or is this a bug? > > (I see two different problems which might have the same cause: > > - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to > > the 'whois -h whois.ripe.net "Matyas Matyas"'? > > - why does the WAIS not give me the person object MM200-RIPE? > > ). > > > > I could explain however the behaviour of the WAIS query by the fact that it > > does not search the "real" database, but a copy of it, which is updated in > > bigger chunks. Is this the explanation for the second problem? > > Correct, WAIS gets updated only once a day. We can should be able to see > the object tomorrow. > > > I find no explanation for the first problem though... > > I think that we are dealing with a 'feature' and possibly a bug (I need > to investigate this in more detail to be sure). > > The database uses the following algoritm to find an object: > > - break up the search key on space boundaries: > > Matyas Matyas ----> (Matyas, Matyas) Thank you for your detailed answer. I think I have now better delimited the problem, which seems to be a _bug_ also after the explanation you gave. Based on your description of the algorithm I would definitely assume that the result of the query whois -h whois.ripe.net "Matyas Matyas" should be the same as the result of the query whois -h whois.ripe.net Matyas Am I correct? The problem is that they are NOT the same! The correct result is provided only by the second query. :( The first one _excludes_ only the correct answers, instead of _returning_ only those values? This looks like a condition written in a negated form... Best regards, Janos > > - Then it looks for objects that match the keys > > Dedi Matyas (Dedi, Matyas) > > Example: > > Matyas -> 3,5,10 > Dedi -> 5 > > - It returns the objects that are pointed by all the keys (not one of > them) but ignores keys that don't reference anything: > > Thus a query for: > > Matyas Matyas > > will give you back any objects that have a Matyas key (objects 3,5,10) > > and > > Dedi Matyas > > will give you object 5 (not 3 & 10) > > > It looks like the database gives consistent output except for the > following case: > > $ whois -r Matyas Matyas > > person: Dedi Matyas > > because the above described algoritm should give you all objects that have > a key Matyas and should give the same result as the following query: > > $ whois -r Matyas > > person: Dedi Matyas > ... > person: Matyas Matyas > ... > person: Matyas Matyas > ... > > > I made some completely new code for this part of the RIPE database in my > own time but it is far from production quality but the problem is on the > list (This code also solves the 'too many hits' problem for people with > very common first and last names). > > Note that it is recommended to do your first search with a not too refined > key: You cannot always be sure that people that registered a person had > the same idea of the first name of a person (only initials, full name). > > Thanks for noticing and informing me of this problem. It will certainly > be looked into, > > Kind regards, > > David Kessens > RIPE Database maintainer > ---- >

2 1

bug in the whois/wais query?
by zsako＠banknet.net 03 Apr '96

03 Apr '96

Hello, I have noticed a problem with a person called Matyas Matyas. I needed him in the RIPE database. I queried the database and got: whois -h whois.ripe.net "Matyas Matyas" person: Dedi Matyas address: RADCOM Ltd. address: 8 Hanechoshet St. Tel-Aviv 69710, Israel phone: +972 3 6472694 fax-no: +972 3 6474681 e-mail: dedi(a)radcom.co.il nic-hdl: DM55-RIPE notify: lir(a)NetVision.net.il mnt-by: NNCC changed: steiff(a)NetVision.net.il 960225 source: RIPE I therefore registered the following person: person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40 65 16 65 16 fax-no: +40 65 16 62 90 e-mail: matyi(a)hotsoft.vsat.ro nic-hdl: MM200-RIPE notify: ncc(a)banknet.net changed: zsako(a)banknet.net 960403 source: RIPE I queried the database in the same way and I got the same result as the first time! Therefore I suspected the person had been registered earlier and I queried the database with the WAIS option (through telnet info.ripe.net). I looked for the word "Matyas" and I got three results, one of them was the object below: person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40-65-166516 fax-no: +40-65-166290 e-mail: matyi(a)hotsoft.vsat.ro nic-hdl: MM184-RIPE changed: alina(a)u1.ici.ro 960326 source: RIPE and two irrelevant person objects, but the person with the NIC-handle MM200-RIPE was not there! I got a similar result with a different keyword ("matyi" from the e-mail address) and again got MM184-RIPE, but not MM200-RIPE. Is this normal (did I miss something) or is this a bug? (I see two different problems which might have the same cause: - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to the 'whois -h whois.ripe.net "Matyas Matyas"'? - why does the WAIS not give me the person object MM200-RIPE? ). I could explain however the behaviour of the WAIS query by the fact that it does not search the "real" database, but a copy of it, which is updated in bigger chunks. Is this the explanation for the second problem? I find no explanation for the first problem though... In case I missed something please excuse me for polluting your mailbox and taking your time... Best regards, Janos PS. I will delete the person MM200-RIPE next week, but I want to leave it there for the moment in case somebody wishes to investigate the problem.

2 1