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

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