August 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

Draft Agenda LIR-WG 37
by Hans Petter Holen 12 Sep '00

12 Sep '00

1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 35 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN ICANN Status of the Latin and AFRI NiCs 6. Report from the address council 7. Presentations of candidates for the AC election 8. Status of the ICANN ad Hoc group 9. Report from the 17th of may Task Force 11. AOB.

1 2

ANNOUNCEMENT: Second Public Beta Release of Asused
by Maldwyn Morris 08 Sep '00

08 Sep '00

Hi, The RIPE NCC are pleased to announce the release of a second public beta version of Asused. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The main changes have been to tidy the code and to merge the code ( and version number ) for our internal tool with that of the public version. The only part missing from the public version is now that which performs checks using information that is proprietary to our members. We have also fixed some bugs in the software found by internal and external users: * Free space at the beginning of an allocation was not handled correctly * Some overlapping assignments were being missed. * Assigned address space was not always calculated correctly. * Overlaps caused more than 100% usage. Thanks for the bug reports. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.5.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. We are keen to receive your feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 1

Address Space Waiting Time...
by Feico Dillema 04 Sep '00

04 Sep '00

Hello, I filed a first request for address space for a new LIR about a week ago. Ticket number is NCC#2000085969 and it's still in the waiting queue. Can any of you give me a hint on what the average queuing time is at the moment? My boss is getting a bit nervous as it is on the critical path for meeting some deadlines, and I'd like to be able to tell him whether he can relax or should panic... Thanks, Feico.

3 3

RE: ripe-db question
by Christian Storch 02 Sep '00

02 Sep '00

Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. - Perhaps that page could solve your question. regards, Christian //========================== // Christian Storch // InfraNet AG // Niederlassung Muenchen // Hansastr. 136 // D-81373 Muenchen // phone: +49 89 743523-55 // fax: +49 89 743523-23 // E-mail: storch(a)infra.NET //========================== -----Original Message----- From: mediaWays Hostmaster [SMTP:hostmaster@mediaways.net] Sent: Wednesday, August 30, 2000 4:24 PM To: lir-wg(a)ripe.net; db-wg(a)ripe.net Subject: ripe-db question Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

2 1

ripe-db question
by mediaWays Hostmaster 02 Sep '00

02 Sep '00

Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

7 8

Is this normal behaviour?
by Marco Davids 01 Sep '00

01 Sep '00

Hello, A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result. The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones. Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now. But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not? -- Marco Davids / SARA - Academic Computing Services Amsterdam Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt

7 7

IP allocs on the NAPs/IXs
by Berislav Todorovic 31 Aug '00

31 Aug '00

Hello, Apologies if this is a FAQ, but I really didn't find any site that contains a list of IP address allocations/assignments for various Internet exchange points worldwide. Is there any list of NAP addresses available? Such a thing would be useful to filter out leaking NAP address announcements from peers. Thanks in advance for any information! Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Wilfried Woeber, UniVie/ACOnet 31 Aug '00

31 Aug '00

>Subj: RE: SLA's needed !!! (Was: Re: ASN wait time) IMHO, it's "fairly" simple to get this problem under control: Assumptions: - the RIPE NCC is working for it's members and for the common good of the (european) Internet (providers, and thus, indiretly users). - RIPE and the RIPE NCC's Members define and approve (by providing the NCC's funding) the rules which govern the distribution of Internet Resources, as implemented on a day-to-day basis by the hostmasters. Requirement: (under the assumption - to be verified - that indeed there is still a performance problem at the NCC) - get the community to review the usefulness and the boundary conditions of the existing policy framework. - get the community to review the allocation of resources to the NCC to implement these policies. - get the NCC to implement an *internal* feedback loop which breaks the vicious circle of (sometimes perceived as unilaterally) tightening operational rules (with good intentions, indeed!) when the additional resources are not available to cope with the additional workload. I'd say that many (all?) of those things are being worked on already, in one way or another. Although the positive effects of those efforts might still not be obvious to the community at large... <Rant> Thinking in terms of money is not a useful approach here, for many reasons as already given during the discussion and some others, too, because what you/we (the customers) really want to obtain is _fast_ *and* _fair_ access to (sometimes perceived as limited) Internet Resources. I guess most of us are not interested in the first place to save money or to spend additional money when doing so wouldn't have any positive systematic impact on the resolution of the underlying problem... </Rant> -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Jorma Mellin 31 Aug '00

31 Aug '00

>service. So, if a LIR decides to have an SLA-bound agreement, it will pay N >times more (N may be even 10 or 20) than a standard contribution fee, but >will get guaranteed service. If RIPE NCC fails to provide service to those >registries, they would pay penalties, which would be automatically deduced >from the LIR contribution fee. > >All other registries should pay normal fees and get normal class of service >(not SLA bound, no penalties for delays etc.). I't doesn't sound too good, because in that model you can use money to obtain better service. So that model is going to hurt the LIR's who are not willing or able to pay. I know my employer can easily afford to pay to get the service we want, but somehow it doesn't sound right when we are talking about a resource (IP addr. space) what should be divided among users as equally as possible. But, if every LIR would agree to pay a small amount if service is running smoothly then we are all at the same level. And it doesn't require an application to keep track who has what SLA. So far I haven't hear a fact that the long delays are caused by lack of human resources. It has beeing an assumption so far. If it really is a manpower problem how many people we do need more and how much money it takes to hire and train them? BTW, I have handled the problem with queues so that we do not make any exact promices to our customers that they can have numbers an a given date. More or less we explain that there is a process behind all this and it is there because of a reason. 99% of them are happy with that. Problems usually start when too optimistic promices are beeing made (by someone not familiar with the process). Jorma

2 1