- db-wg - mailman.ripe.net

RE: Loop in AS macro
by Wilfried Woeber, UniVie/ACOnet 10 Jan '01

10 Jan '01

Hi Gilles, I guess we wouldn't be able to check against those accidents at the time of a DB _update_... But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project? Henk, any comments? An interesting aside: I guess similar problems could occur with RPSL-based RRs? -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, admin-c(a)tli.de CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache(a)cc.in2p3.fr> Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 20001103 changed: toba(a)tdk.dk 20001117 changed: tee(a)tdk.dk 20001123 changed: jesper(a)skriver.dk 20001228 changed: jesper(a)skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering(a)tli.de mnt-by: TALKLINE-MNT changed: thomas(a)tli.de 19990923 changed: thomas(a)tli.de 19991020 changed: thomas(a)tli.de 19991025 changed: thomas(a)tli.de 20001023 changed: thomas(a)tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 19990922 changed: jesper(a)skriver.dk 19991019 changed: jesper(a)skriver.dk 19991025 changed: jesper(a)skriver.dk 19991210 changed: toba(a)tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------

6 6

RE: Loop in AS macro
by Christian Storch 10 Jan '01

10 Jan '01

Please don't say 'include'. - What about "expand" as Shane used it already? So think about a macro as a set of AS'es and only form the set union of it. Every AS should be a set of size 1 and a macro a set of size n. As a result you would get an infinite iteration but A = B! So if somebody would suggest it to be nonsense, what about Pi etc.? ;-)) I think a script has only to expand a macro and to insert it into a list of already expanded macros. ... Christian -----Original Message----- From: Gilles Farrache [SMTP:farrache@cc.in2p3.fr] Sent: Wednesday, January 10, 2001 12:17 PM To: Shane Kerr Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net; farrache(a)cc.in2p3.fr; Jesper Skriver Subject: Re: Loop in AS macro Shane and al, When I was at school (a long time ago) I learn what was called the "set theory" ( "Theorie des ensembles" in French) that was part of what was called the NEW Mathematics. In those courses I learned that : If set A is included in set B and if set B was included in set A then A = B. Whet your telling me is that there are New New mathematics (as there is a new economy) in which : if set A is included in set B and set B included in set A that does not implie A = B. I am very interrested by that theory and will be happy that you give me some pointers to it. :-) Or what is an AS-MACRO ? It is a set of AS (or a set of set of AS ....). So they have to follow the set theory. Gilles

2 1

Loop in AS macro
by Gilles Farrache 10 Jan '01

10 Jan '01

Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 20001103 changed: toba(a)tdk.dk 20001117 changed: tee(a)tdk.dk 20001123 changed: jesper(a)skriver.dk 20001228 changed: jesper(a)skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering(a)tli.de mnt-by: TALKLINE-MNT changed: thomas(a)tli.de 19990923 changed: thomas(a)tli.de 19991020 changed: thomas(a)tli.de 19991025 changed: thomas(a)tli.de 20001023 changed: thomas(a)tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 19990922 changed: jesper(a)skriver.dk 19991019 changed: jesper(a)skriver.dk 19991025 changed: jesper(a)skriver.dk 19991210 changed: toba(a)tdk.dk 20000903 source: RIPE

3 4

RIPE Whois RPSL Migration
by RIPE NCC 21 Dec '00

21 Dec '00

[ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC

1 0

Announcement: RIPE Whois Database version 3.0 beta is out
by RIPE Database Administration 08 Dec '00

08 Dec '00

Dear All, [ Apologies for duplicate messages ] This mail is to inform you that version 3.0 beta of the RIPE Whois Database is out. Read on! You will be affected too. The RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". The version 2 of the RIPE Database, the one currently in production on whois.ripe.net, will in the next months be replaced by version 3. All the entries in the RIPE Database will be translated into RPSL format, and that is the format you will get when you will be querying the Database. Don't be mistaken: for the moment, whois.ripe.net continues running with version 2 and answering to your queries in the old-fashioned way. But this will not last forever; in a few months, all will become RPSL. So if you use the Whois database, we encourage all of you to prepare for this change as soon as possible. We strongly suggest you to start to get used to RPSL and version 3.0 . In this aim, you can do the following: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. We are currently preparing additional resources to help ease the transition; we will announce them as soon as they are available, which will happen later this month. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. For the ones interested in viewing or trying the code, you can download it at: ftp://ftp.ripe.net/ripe/dbase/reimp/whois-rip-3.0beta1.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, The RIPE Database Group.

1 0

Re: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 01 Dec '00

01 Dec '00

I've tried to sort some of the various aspects/expectations. Lets see.... => It depends on the level of "responsibility" and functionality granted to => and exercised by that end site. As I've said in a private mail already, => we should ask the question about the usefulness of "assigning" (in the => good old sense) very small amounts of addresses to sites which are tied => in to the services of their provider anyway. I guess most of the ADSL, => dial-up, cable-TV connection assignments sh/could be reviewed from that => point of view. = =The name and address info in the RIPE database needs to contain the =person (or organisation) responsible for a certain amount of IP space, =in my opinion. = =So, if an ISP wants to be responsible for the IP space it hands out to =customers, then the ISP should be free to fill in their own name and =address. This gives ISPs the freedom to fill the RIPE db with names =and addresses of customers (that saves them the hassle of dealing with =for example abuse coming from that site), or putting their own name =in it (meaning they have to respond actively to for example abuse reports, =which is the ISP's job anyway). 1) IP-Addresses are taken from a globally unique pool. Thus the global Internet community expects to have access to publicly accessible registry data to query the status (unassigned/reserved - allocated - assigned) for a particular address or address block or other unique resource. 2) The contact information listed for the individual resource serves 2 purposes: a) it offers info to get in contact with a human being to resolve connectivity problems (IP or application layer) between end sites b) it offers info to get in touch with a human being in case of operational problems that have an unwanted impact on the performance or security of networks other than the source of the problem (routing issues, spam, abuse). Ref: 1: While I still think that the open availability of that info is essential for the responsible and continued operation of the Internet, it can be argued whether contact info to get in touch with a human being has to be publicly available. In the long run, we probably have to deal with the authorities in one way or another (on a national and international level), to get the existence and maintainance of such a global registry recognized and endorsed. Ref: 2)a): While "we" certainly have become comfortable with the notion of being able to "talk" to everyone who is on the net (to resolve operational problems for our own applications or customers), we might have to let go here - and also to openly tell *our* customers, that we cannot help in case of problems when the "other end" opts to remain anonymous (by requesting contact info to be suppressed or, better yet, not to be collected at all). Ref: 2)b): I think it is - as much a resonable expectation held by all people and sites and backbones on the net that their network(s) can be protected against misuse (proactively), or that any incidents can be resolved quickly and easily, - as it might be reasonable to request anonymity on the net for end sites. I guess we have similar situations in real life, where there is a conflict of expectations and interests between the individual and the community, like . license plates on vehicles to follow up on violation of rules, . a public registry for real estate ownership to settle ownership claims . or to track down the owners in case the patch of land becomes a source of danger or nuisance for neighbours, . registries for companies, their legal representatives and financial backing (which many would certainly prefer not to disclose :-) . registries for the address of citizens in case they do not live up to contractual obligations So, would we be better off by following up on our "IRT-pointer" proposal and then offer the alternative to supply - *either* the end users's contact information - *or* the contact information for an IRT that has accepted responsibility for the operational use of that resource? In most cases, and for small end-user sites, this would be ISP staff, anyway. Having a certain resource listed in the registry without any contact information (neither individual contact nor IRT/ISP contact) should be seen as a _strong_ hint to exercise strong care in dealing with that site - by applying whatever means available to minimize the impact of misconfiguration and/or attacks originating from those sites. This could indeed limit the usefulness of those resources on a global scale, much like you are allowed to obtain and drive a vehicle without registration and thus without a license plate on private property - but this vehicle gets filtered or blocked on any public road :-) Comments? Wilfried. _________________________________:_____________________________________ 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: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 30 Nov '00

30 Nov '00

=> I'm writing for your opinions, suggestions, and comments regarding updating => the RIPE database with assignments made for broadband (xDSL) customers. As => you may or may not be aware, ADSL is now being offered in the UK, which => has very strict data protection laws. We offer ADSL services as a NATted = =IP addresses and data related to them is international resource. =I don't think you should apply any law in UK when we talk about =RIPE(.int) resources. But that doesn't mean the people *collecting* customer related info *and transferring that data to somewhere abroad* would be exempt from local laws. Quite the opposite holds true for many (most?) countries... =I assume we are still supposed to maintain single nic-hdl per person. =What's the plan now, if my LIR would need to refer to the same contact =person? It doesn't make sense to direct any calls to your LIR, if the =problem lies at customer network at our LIR's addresses. It depends on the level of "responsibility" and functionality granted to and exercised by that end site. As I've said in a private mail already, we should ask the question about the usefulness of "assigning" (in the good old sense) very small amounts of addresses to sites which are tied in to the services of their provider anyway. I guess most of the ADSL, dial-up, cable-TV connection assignments sh/could be reviewed from that point of view. => phone: +44-845-272-0444 => remarks: Phone is Demon Internet Helpdesk = =The same rule should apply to all assignments. If a (home) network =contact person doesn't want to be 'listed', s/he can try to live =without real network and buy NAT from a provider. That's a very valid point. =If people think RIPE db contains too much sensitive information, =I would rather see the query results restricted somehow. For example =operators (LIRs) could have full query access, and the others =could merely receive pointers to the LIR for further information. This idea happens to pop always now and then, again and again. the last time I heard a proposal along those lines was at the Brisbane APNIC meeting. I then asked the following question: "So you are going to collect information, but you are going to hide it. Fair enough. Have you thought about criteria and/or mechanisms to disclose that information, either to entites with a "valid" interest and/or to law enforcement?" I did not receive a useful answer. Just as a virtual poll - would anyone in the RIPE region care to propose criteria and/or mechanism? Wilfried. _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problems with windows? re-boot! Problems with unix? be root!

4 3

Re: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 30 Nov '00

30 Nov '00

>The name and address info in the RIPE database needs to contain the >person (or organisation) responsible for a certain amount of IP space, >in my opinion. I agreee, and the important word here is "responsible". >So, if an ISP wants to be responsible for the IP space it hands out to >customers, then the ISP should be free to fill in their own name and >address. Doing that means that an assignment (*to the customer*, in the traditional sense) has not been performed. >This gives ISPs the freedom to fill the RIPE db with names >and addresses of customers (that saves them the hassle of dealing with >for example abuse coming from that site), or putting their own name >in it (meaning they have to respond actively to for example abuse reports, >which is the ISP's job anyway). This is very similar to my reasoning regarding the usefulness of performing an assignment for a (small) site which does not fully (independently and in a responsible way) manage their address space. Wilfried.

1 0

Privacy, Broadband, & the Database
by Sam Bradford 29 Nov '00

29 Nov '00

Hello all. (Apologies if you got a 'subscribe' message from me earlier. I wasn't thinking about Majordomo for some reason.) I'm writing for your opinions, suggestions, and comments regarding updating the RIPE database with assignments made for broadband (xDSL) customers. As you may or may not be aware, ADSL is now being offered in the UK, which has very strict data protection laws. We offer ADSL services as a NATted service (with one large entry in the RIPE database like for dial-up customers) and a non-NAT service that includes an IP assignment. Our concern is that a large percentage of our non-NAT ADSL customers are either home users or home businesses. Updating the RIPE database with an IP assignment requires an end-user Admin contact, and the person object requires a telephone number. Worst case scenario is that we update the database for a home business or a home user with the customer's telephone number, his teenage daughter enters a chat room, and you can imagine the rest... After brief consultation with the RIPE NCC Hostmasters, we have begun updating the database with our role object as Tech Contact and the customer as Admin contact. For the phone number, we are using our own, noting as much in a 'remarks' field. For example: inetnum: 62.49.8.64 - 62.49.8.79 netname: PYAR-ADSL descr: DEMON ADSL CUSTOMER country: GB admin-c: PY84-RIPE tech-c: DHG5-RIPE status: ASSIGNED PA notify: hostmaster(a)demon.net mnt-by: AS2529-MNT changed: hostmaster(a)demon.net 20001115 source: RIPE <snip DHG5-RIPE> person: Phil Yarranton address: GB phone: +44-845-272-0444 nic-hdl: PY84-RIPE remarks: Phone is Demon Internet Helpdesk notify: hostmaster(a)demon.net mnt-by: AS2529-MNT changed: hostmaster(a)demon.net 20001115 source: RIPE However, I'm not sure that is the best option, and could lead to inconsistency. At what point do we determine (and should we determine?) if an obvoius business customer is home-based or office-based? Should we have one set of rules for the database for leased line & ISDN customers and another for ADSL? Or one set for business customers (regardless of home-based or office-based) and another for home users? Looking forward to your comments. :-) Sam Bradford ----------------------------------------------------------------- sam bradford, senior hostmaster sam.bradford(a)demon.net Demon Internet / Thus plc . hostmaster(a)demon.net Tel: +44-845-272-0666 . . http://www.demon.net/ Fax: +44-20-8371-1285 t h u s http://www.thus.net/

3 3

About the Hermes Project
by Andrea Carmignani 06 Nov '00

06 Nov '00

Hi my name is Andrea Carmignani, I belong to the network research group of the university of Roma3. We developed a tool, known as Hermes, able to explore the Internet topology. Its based mainly on the information coming from the databases belonging to some Internet Resource Record like RIPE, RADB, VERIO, CABLE & WIRE, ARIN and BELL in addiction to the BGP routing information coming from the Route Projects of the Oregon University. Hermes is able to dynamically explore the Internet Topology, providing a Map representing the As and their interconnections. For any AS present on the map, it can also provide several information like: AS name, Maintainers, Routing Policies, list of the known border Router, list of the routes originated by the AS and the As macro which the AS belongs. We will be grateful if you could give us some feedback on the real utility of this tool and hopefully some suggestion able to improving it. Please visit the URL: http://www.dia.uniroma3.it/~hermes here you will find a more detailed paper, some screenshot galleries, a screencam of the tool working and you will able to use Hermes through the Applet provided. I think this is the right mailing list where to post this news if not I apologize otherwise Thanks in Advance Andrea

2 1

reimp.ripe.net (rpsl.ripe.net) server is temporarily unavailable
by Andrei Robachevsky 27 Oct '00

27 Oct '00

Dear Colleagues, Yesterday a machine that was used for the new prototype DB server crashed and could not be restarted due to hardware problems. We are working on this and will bring the prototype server up as soon as possible. Sorry for any inconvenience. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Re: mark
by Randy Bush 29 Sep '00

29 Sep '00

> -----BEGIN PGP SIGNED MESSAGE----- > > person: Mark Bold > address: Verio/UK sigh. apologies. i think i made this same address book stoopid once before. sorreeeee. randy

1 0

RIPE NCC to shut down rpslii.ripe.net on November 6
by RIPE Database Administration 22 Sep '00

22 Sep '00

Dear All, [This does *not* affect the RIPE whois database at whois.ripe.net] As you know, the RIPE NCC has provided a test RPSL database for a few years. This database software (available for queries at rpslii.ripe.net) was written in perl and was set up so that the community can experiment with RPSL. It was around since the time of RPSL drafts. As the reimplementation project is approaching the end, we have set up two instances of the new software at reimp.ripe.net. One of them is a mirror and the other a test database. The purpose of the new test database is exactly the same as of the old perl version. Therefore we decided to shut down the old RPSL perl server at rpslii.ripe.net. This will happen on November 6, 2000. The data accumulated in that database will be lost. You can use the new RIP Test Database already. Updates to this database should be sent to <auto-rip(a)ripe.net> and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the new implementation and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Marek Bukowy ____________________________ RIPE Database Administration.

2 1

Re: auto-dbm quirks
by Steven Bakker 21 Sep '00

21 Sep '00

>>>>> On Thu, 21 Sep 2000, "MR" == Matthew Robinson wrote: MR> I have the "joy" of sitting behind an Exchange server and I can from MR> the 'Format' menu select plain text only which fixes this problem. I MR> suspect that there is more config on the server itself but as an MR> example this message should be plain text. It is, but the Exchange server itself apparently forces the multipart/ alternative, though only for clients that send their mail through the proprietary Exchange protocol. Straight SMTP to the server seems to work fine. In corporate-honcho type environments this may be dandy; keyboard monkeys are less than happy with it. Cheers, Steven (wishing nmh could do "virtual folders" on top of IMAP).

2 1

auto-dbm quirks
by Steven Bakker 21 Sep '00

21 Sep '00

Hi folks, A few people have asked me to help them out with a nasty problem they're having. They are stuck behind a braindead ms-exchange server and corporate standards apparently prevent the use of SMTP, POP or IMAP. Hence, these people have to communicate using the Exchange protocol. Now, when the Exchange server has to send mail to the real^H^H^H^Houtside world, it will use a pesky "connector". And here's the catch: that connector has been configured to send mail as both plain text _and_ HTML, resulting in, you guessed it, one of those wonderful "multipart/alternative" hybrid freaks (can you tell I'm not a fan?). So, what's the big deal, you ask? These friends of mine are trying to send updates to the RIPE database, making do with the crummy mail software they have at their disposal. Unfortunately, the auto-dbm robot does not understand multipart/alternative, nor any other MIME encoding. In fact, as far as I can tell from its diagnostics, it completely ignores any Content-Type: header and simply treats the message as plain text. Now, I agree, the Exchange mail setup leaves a lot to be desired, but the mail it sends out _is_ standards compliant. The auto-dbm is the one that's non-compliant. There are two ways that I can see to fix this: 1. Look for a content-type:- header and INSIST on text/plain. This doesn't solve my friends' problems, but it would at least provide more intelligent diagnostics. 2. Do some MIME parsing, allowing both text/plain and multipart/alternative. In the case of multipart/alternative, INSIST on a text/plain part. Maybe even decode base64 or quoted-printable? Would be handy in case there are more crummy mail systems out there... I don't think the MIME parsing would be so difficult. Decoding base64 or quoted-printable shouldn't be that hard either. Is this something that can be done quickly, or at least put on a priority list? I foresee that in the near future more people will be forced to embrace the MS-Office dogma and suddenly find they cannot update their RIPE objects anymore. Cheers, Steven

4 3

DB RPSL migration task force
by kieber＠ga-telecom.net 15 Sep '00

15 Sep '00

Re, at RIPE37 we have agreed to put a task force in place to prepare for migration to the new RPSL database, and I'd like to take the opportunity and solicit for members to this task force. Purpose of this task force should be finding the bugs in the new code before it is put to real work. Please review the migration plan at http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps We also want to raise awareness that the new database is actually in RPSL format, so there are some significant changes to RIPE-181 format. If you are using scripts to query or update the database its very likely you have to adapt those scripts and the task force would like to benefit from your experiences when playing with the new database and testing your tools. While RIPE NCC is using a test suite to test the new database the best test is having real users beat on it. Remember, you will have to live with the bugs the task force doesn't find. If you are interested in participating, please, get back to me and I'll have you added to the mailing list <reimp-mig-tf(a)ripe.net> -- Ulf Kieber email: kieber(a)ga-telecom.net Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.ga-telecom.net

1 0

CERT Object and friends
by Wilfried Woeber, UniVie/ACOnet 15 Sep '00

15 Sep '00

Dear Andrei! Following up on today's discussion, could you please send the CERT Object (pre)draft, that you were showing to me a short while ago, to the DB-WG List? Then we can start to think about any modifications (or alternate approches), and what a presumed deployment could look like. TIA, regards, Wilfried.

2 1

Whois discussions
by Patrik Fältström 14 Sep '00

14 Sep '00

The name of the whois-ext mailing list is: ietf-whois-ext(a)imc.org What has been discussed so far is drafted in draft-faltstrom-whois-04.txt (which doesn't mean that should be the basis for the discussions up to the BOF in December). Randy talked about differnet things at the talk today, and the RPSL specification didn't exist when Mark and myself wrote the draft. Patrik

1 0

draft agenda (v4), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 12 Sep '00

12 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 4th draft, proposed agenda for the DB-WG Meeting. This draft is the result of our attempts to resolve the WG schedule collisions. The proposal is to rearrange items, to run an extended 1st part (in _parallel_ with Routing), an then to continue with a _joint_ Routing and DB-WG session (after a probably belated coffee-break) to deal with items closely related to both camps. My apologies for this mess, but I guess this is the best thing that we could do - given the constraints that were imposed on us. Still, comments, suggestions and additions are welcome. Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 4. Draft Thursday, Sept 14, 2000 starting at 09:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: DB-WG Meeting PI-A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed PI-B. Actions Items . PI.C. RIPE DB, operations update (RIPE NCC) 20min PI.D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min PI.E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) PI.F. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact PI.G. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? PI.H. IRT-Pointer for DB Objetcs (WW) 10min . consensus to go ahead? . which Objetcs? PI.Y. Input from other WGs - CENTR Tech: . protect vulnerable TLD objects? . remove "bogus" TLD objects? . "best before" on person (& role) objects? PI.Z. AOB: Part II: Joint Session with Routing PII.A. New Database implementation (RIPE NCC) PII.B: RE-Implementation/Migration TF . Test Reports/Feedback . Deployment Plan . Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 12-SEP-2000 19:56:46 _________________________________:_____________________________________ 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

draft agenda (v3), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 10 Sep '00

10 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 3rd draft, proposed agenda for the DB-WG Meeting. This draft improves on the numbering, and lists an additional item: - Incident Response Team pointer for DB objects As we still have a few scheduling problems to resolve, please expect some re-arrangment of the sequence of items! As usual, comments, suggestions and additions are welcome. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting PI-A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed PI-B. Actions Items . PI.C. RIPE DB, operations update (RIPE NCC) 20min PI.D. New Database implementation (RIPE NCC) 40min PI.E. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min PI.F. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) PI.G. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact PI.H. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? PI.I. IRT-Pointer for DB Objetcs (WW) 10min . consensus to go ahead? . which Objetcs? PI.Y. Input from other WGs - PI.Z. AOB: Part II: Re-Implementation/Migration TF PII.A: Members, ToR PII.B: Test Reports/Feedback PII.C: Deployment Plan PII.D: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 10-SEP-2000 17:28:07 _________________________________:_____________________________________ 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

draft agenda (v2), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 07 Sep '00

07 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 2nd draft, proposed agenda for the DB-WG Meeting. This draft fixes an omission: - Recommendation on the use of "auth:" methods (editorial fault) and lists an additional item: - globally unique handles for "person:" and/or "role:" As we still have a few scheduling problems to resolve, please expect some re-arrangment of the sequence of items! As usual, comments, suggestions and additions are welcome. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed B. Actions Items . B. RIPE DB, operations update (RIPE NCC) 20min C. New Database implementation (RIPE NCC) 40min D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) F. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact G. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? Y. Input from other WGs - Z. AOB: Part II: Re-Implementation/Migration TF A: Members, ToR B: Test Reports/Feedback B: Deployment Plan C: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 7-SEP-2000 18:55:48 _________________________________:_____________________________________ 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

RIPE whoisd re-implementation: RIP-0.5.0beta1 software snapshot
by RIPE Database Administration 06 Sep '00

06 Sep '00

Dear All, This mail is to notify you that today, we have frozen the source code of the new implementation of the RIPE Database software into a new snapshot. The main new feature of the last snapshot is that the PGP signed messages are now handled by the software, i.e. the PGPKEY authentication scheme is supported. Moreover, more inverse queries have been implemented (-i upd-to and -i mnt-nfy), and several bugs have been fixed. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.5.0beta1.tar.gz We remind you that you can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. This mirror is in RPSL format. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group.

1 0

draft agenda (v1) for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 06 Sep '00

06 Sep '00

Dear WG list members, fellow chair persons, "meeting", attached please find the 1st draft, proposed agenda for the DB-WG Meeting. A few minor items might get added later this week. While the general outline of the meeting should be quite stable already, please expect some re-scheduling due to the parallel WG streams. This requires us to do some "micro-management" to avoid "over-booking" of individuals. As usual, comments, suggestions and additions are welcome! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting A. Administrative stuff (Wilfried Woeber, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed B. Actions Items . B. RIPE DB, operations update (RIPE NCC) 20min C. New Database implementation (RIPE NCC) 40min D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) Y. Input from other WGs - Z. AOB: Part II: Re-Implementation/Migration TF A: Members, ToR B: Test Reports/Feedback B: Deployment Plan C: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 6-SEP-2000 13:44:48 _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First things first, but not necessarily in that order....

1 0

RIPE 36 DB-WG Minutes (final version)
by Nigel Titley 04 Sep '00

04 Sep '00

Gentlefolk, After receiving comments. Here are the final minutes of the RIPE DB-WG minutes. Share and enjoy. Nigel Minutes for the Database Working Group Meeting RIPE-36, May 2000, Budapest, HU Thursday, May 18, 2000 at 10:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) . scribe Nigel Titley volunteered to take the minutes . raw scribe notes distributed Wilfried had not had time to process the raw notes from RIPE 35, but these were circulated in lieu of full minutes. . help offered by - Nigel Titley, - Ulf Kieber Wilfried asked the WG if they were happy to accept the help offered by Nigel Titley and Ulf Kieber. Nigel would help with the PR and documentation side of the group, and Ulf will help to co-ordinate the working group. He received approval from WG on this issue. B. RIPE DB, operational update (Andrei Robachevsky, RIPE NCC) Andrei Robachevsky gave an operational update on the state of the RIPE DB. Amongst the many statistics that he presented it was noted the very large number of domain objects, mostly from the .de domain. It was explained that these objects would be shortly devolved to the DE-NIC whois server, and plans were currently being formulated to perform this move with minimum disruption to the RIPE community. C. DB Software Re-Implementation (Joao Damas, RIPE NCC) Joao Damas gave a short presentation on the progress of the DB Software re-implementation project. D. Report on Certification Authority activities (Paul Gampe, APNIC) Paul Gampe gave a very interesting presentation on the use of X509 certificates for authentication when updating the APNIC database. The following points were noted: - Training at the next RIPE meeting might be useful, to provide a view of X509 vis-a-vis PGP. There appears to be a degree of convergence between the two systems. - It was noted that it will be soon possible to sign X509 keys with PGP signatures and vice versa. - The main objection to using X509 is the cost of the commercial licenses. The first phase of the implementation will sort out licenses for users. Much cheaper (free) approaches are on their way. E. Activity Plan for next year! It was noted that input to the RIPE-NCC activity plan was needed before September. Suggestions received from the WG included - Use of X509 signature for authentication (as per APNIC) - Support for other character sets than ASCII. (Joao noted that the new code is 8-bit clean, but that there is problem wit the reproduction of character sets. The best he felt able to do was to track progress by other sources, and to keep the code clean). - Removal of further domain objects from the database. The problem being that existing applications must not be affected. It was suggested that the RIPE-NCC could offer help to other ccTLDs to set up their own whois databases. It was suggested that we ask CENTR to produce a regular report and to try and get domain objects shifted out of the DB. [AP: Wilfried Woeber and Joao Damas] F. Input from other WGs - EIX-WG would like an object in the DB to describe IXs. It was also suggested that a peering contact in the aut-num object could be useful. There was some support for both these proposals and it was suggested that a formal request be made to the WG by email. - Routing WG. No further input had been received from the Routing WG re native multicast. It was felt that this would soon need looking at. The Routing WG needs to add an entry to the RPSL Draft. G. AOB - A suggestion (Joel Rowbottom) was made to use XML for registration templates. Suggestions as to how to do this would be gratefully received. - A suggestion to use a mail-to authentication scheme was received from Michael Battilana (IANA). The idea being that agreement to proceed with a modification would be obtained via a token and confirmation from a know mail mail address. It was agreed that this was not very easy to do as it is stateful and could lead to DOS attacks on the database. - A brief update was given on CERT/IRT-related issues (WW144/Jaques Schuurman). Ut was suggested that a pointer be added to inet-num object to point to the IRT role. Anyone interested in this work to contact the WG.

1 0

Re: ripe-db question
by Christian Storch 04 Sep '00

04 Sep '00

You're right! That number space wasn't registrated at RIPE - you have to look at ARIN: http://www.arin.net/cgi-bin/whois.pl?queryinput=NETBLK-SPRINT-CDF4C7 The AS of omnitel looks like the first upstream provider of Omnitel was SprintLink (USA) and the second is Telianet (Sweden). So the address space 205.244.196.0/24 seems to be registrated by SprintLink at ARIN. Later it becomes an LIR at RIPE and so on... So I think for that you would have to ask all RIR's for your purpose: RIPE, ARIN and APNIC. And you won't get always the right answer for your geographical question I think. Christian ---------- | Von: Andrius Kasparavicius <andrius(a)andrius.org> | An: Christian Storch <storch(a)infra.net> | Cc: 'mediaWays Hostmaster' <hostmaster(a)mediaways.net>; lir-wg(a)ripe.net; db-wg(a)ripe.net | Betreff: RE: ripe-db question | Datum: Samstag, 2. September 2000 14:01 | | On Wed, 30 Aug 2000, Christian Storch wrote: | | > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. | > - Perhaps that page could solve your question. | | hmm, look at lt.Omnitel: | lt.omnitel (OMNITEL Net) | 19951120 194.176.32/19 ALLOCATED PA | 19971010 195.22.160/19 ALLOCATED PA | 19990913 212.47.96/19 ALLOCATED PA | | querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 | | route: 205.244.197.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | route: 205.244.196.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | | it mean's that in allocation list, is not all ip blocks allocated to | LIR's. Why? | | Andrius

2 1