May 2000 - lir-wg - mailman.ripe.net

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

"ownership" on ancient network assignments?
by Alexander Bochmann 31 May '00

31 May '00

Hi, we are currently noticing a dispute of two companies over a /16 address range assigned to a predecessor of both of them in 1991 (the original company was split some time ago). We're not a party in this quarrel, but I'm curious about the status of a network that was assigned such a (comparatively) long time ago. Can someone claim to be legally entitled to own this IP address range? What is likely to happen? A. Bochmann -- FreiNet Gesellschaft fuer Informationsdienste mbH Loerracher Strasse 5a D79115 Freiburg

1 0

Auditing tool
by Stephen Burley 30 May '00

30 May '00

Hi I would just like to say the auditing tool is a great success and helps me fix problems before requesting more space thus saving lots of time and effort. I have one suggestion though, when the script shows the percentage used for our network it is still over 90% of the total used even with a /17 spare. This means we still would technically qualify for a new range of addresses ;). I was wondering could the script also show in real terms and not a percentage how much space is available in "/" notation. I know i am being a bit pedantic but its just so we do not hit the panic button when its not needed. Regards Stephen Burley UUNET EMEA Hostmaster

1 0

Delay in processing updates
by RIPE Database Administration 24 May '00

24 May '00

Dear Colleagues, We have currenly a larger update queue than usual. We expect that updates in the queue will be processed in 4-5 hours. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We are sorry about the inconvenience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

RIPE Database crashes ...
by Pascal Gloor 19 May '00

19 May '00

Dear LIR's, What's up with the database ? Do you think it's normal that this machine crashes every 3-4 weeks ? Does RIPE need some more guys to manage that ? I think all LIR's whould be ok to pay RIPE a little bit more fee that RIPE may have a VERY HIGH BIGGER MTBF (Mean Time Between Failure). What do you think about that ? Or what else solution do you have guys (LIR's and RIPE)... to be continued .... Regards, Pascal PGL2-RIPE, AS6893, CH-PETREL Pascal Gloor Network Manager _________________________ SPAN(tm) / Petrel Communications SA A Cable & Wireless company Tél : + 41 22 304 47 47 Fax : + 41 22 304 47 99 E-mail : pgl(a)cw.span.ch Web : http://www.span.ch

5 4

RE: RIPE Database crashes ...
by Pascal Gloor 18 May '00

18 May '00

Mark, sure, i will do it ! but RIPE need to give me access to mirror it :-) Pascal Gloor Network Manager _________________________ SPAN(tm) / Petrel Communications SA A Cable & Wireless company Tél : + 41 22 304 47 47 Fax : + 41 22 304 47 99 E-mail : pgl(a)cw.span.ch Web : http://www.span.ch > -----Original Message----- > From: Mark Lastdrager [SMTP:mark@pine.nl] > Sent: Thursday, May 18, 2000 5:04 PM > To: Pascal Gloor > Cc: lir-wg(a)ripe.net > Subject: Re: RIPE Database crashes ... > > At Thu, 18 May 2000, owner-lir-wg(a)ripe.net wrote: > > >What do you think about that ? > >Or what else solution do you have guys (LIR's and RIPE)... > > Well, maybe you can run a mirror database and give us the hostname? > > > Mark Lastdrager > Pine Internet > > -- > email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: the xy axis in the trackball is coordinated with the > summer soltice

1 0

RIPE Database working normally again.
by RIPE Database Administration 18 May '00

18 May '00

Dear Colleagues, Thank you for your patience. The RIPE Database is working normally again. Updates are being processed and queries are being answered by the primary server. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Daniele Arena ------------- RIPE NCC

1 0

Problems RIPE Whois Service.
by RIPE Database Administration 17 May '00

17 May '00

Dear Colleagues, (Apologies if you receive this message more than once). Earlier this evening, the main RIPE Database server crashed. Your updates are not being processed at this time, but they are being queued; there is no need to send them again. Queries are being processed by a backup server; thus, the response time may be longer than usual. We are aware of the inconvience that this causes you and we are working to restore the service as quickly as possible. We shall keep you informed. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ------------- RIPE NCC

1 0

ANNOUNCEMENT: Beta 0.1 of asused-public released
by John Crain 17 May '00

17 May '00

Dear Colleagues, We, the RIPE NCC, are pleased to announced the release of the beta version of asused-public. This is a tool to summarise address space that is registered in the RIPE database. For a given list of allocations the software prints various information concerning the allocations and the assignments they contain. the software "asused-public" is based on one the NCC's internal tools. It has been revised for public release in a form that does not make use of any customer confidential information. The software which uses several perl modules, these are included, is stored in the following file: ftp://ftp.ripe.net/tools/asused-public.0.1.tar.gz We are keen to receive your feedback on the beta release. Please address your comments and/or suggestions to our Software Manager, Maldwyn Morris <Maldwyn.Morris(a)ripe.net> Yours, John LeRoy Crain Head of Internal Services RIPE NCC

3 2

RE: Warning about the size of the NEXT message
by Jorma Mellin 16 May '00

16 May '00

>As for using public address space in a private enviroment without public AS >numbers iit s very simple, private address space is limited to the ranges >as detailed in the RFC, this network is going to be global and each network >needs to be unique and using private address space would have caused >logistical nightmares. For instance it is envisaged they whould run out of >address space very quickly as 10.0.0.0/8 whould only be enough for >Europe(as have UUNET / Worlcom internal networks), also if you have >independant companies approaching the GPSM initiative from differant sides >of the globe both using 10.0.0.0/8 and then want to connect to each other >directly to enable roaming which company should renumber a multi million >node GPSM network. But the use of private AS numbers is not nearly as >difficult to administer or renumber to allow differant networks to talk to >each other. If the private address space mentioned in RFC is not enough they should go for IPv6. Because GPRS, UMTS and other stuff is brand new I see no problem to implement IPv6 in gateways (and terminals). Another issue is that roarming. Why roarming have to use unique IP numbers to work? You could use application level roarming solution as well and nobody cares if the source addr have gone trough a NAT box or not. This thing is going to get messy when we get first GPRS phones out. >BTW i find it difficult to appreciate how the use of a piece of software to >produce a technical report is a mesure of a persons RIPE compectance, i >would rather say its a measure peoples unwillingness to accept another >practical use of IP into the RIPE community. It's not about the software, it's about usability. I haven't found yet a Word application for my PDA, but I do have a browser :) Jorma

1 0