- db-wg - mailman.ripe.net

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

2 1

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

1 0

Announcement RIPE NCC RRC Training Course
by RIPE NCC Training 17 Feb '03

17 Feb '03

Dear Colleagues, [apologies for duplicate postings] As a new service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT describe how to receive Internet resources from the RIPE NCC not describe to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ----------------------------------------------------------------------- COURSE DATES AND VENUES ======================== Date: Monday 14 April 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Friday 20 June 2003 Time: 0900 - 1700 Location: Kiev, Ukraine ------------------------------------------------------------------------ REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

syncupdates source code release
by RIPE Database Administration 11 Feb '03

11 Feb '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the syncupdates source code release. The release contains: - syncupdates, infrastructure facility to update the Whois server online and synchronously. - webupdates, web based graphical interface for updating objects. The software is available at ftp://ftp.ripe.net/ripe/dbase/software/syncupdates-1.0.1.tar.gz Please contact dbtools(a)ripe.net for any comments. Best regards, -- Can Bican DB Group RIPE NCC

1 0

hint: IPv6 whois presentation in IPv6 WG (only)
by Wilfried Woeber, UniVie/ACOnet 28 Jan '03

28 Jan '03

Dear DB-WG, to avoid duplicating effort in various WGs, there is a presentation about the IPv6 capabilities of the NCC's whois service scheduled in the IPv6 WG _only_. We do _not_ plan to repeat that in DB-WG - although I'd like to add a minor item to the DB agenda to _start_ a "review" activity on IPv6 facilities for the whole machinery. Bottom line: if you are interested in v6 whois - pls. go to IPv6; if you are interested in v6 DB stuff in general - stop by at DB :-) Wilfried. ______________________________________________________________________ Date: Tue, 28 Jan 2003 12:58:33 +0100 From: Andrei Robachevsky <andrei(a)ripe.net> [ ... ] Dear Wilfried, My own opinion: [ ... ] - ipv6 in the DB. Shane is making a presentation on ipv6 whois server (the proxy we put online) This can be replicated at the DB meeting. [ ... ] Thanks, Andrei -- Andrei Robachevsky CTO, RIPE NCC --------------------------------------------------------------------------------

1 0

IPV6 Whois
by DB-News 27 Jan '03

27 Jan '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the availability of RIPE Whois servers on IPv6 network. It is now possible to query whois.ripe.net and test-whois.ripe.net from an IPv6 host, using an IPv6 enabled whois client. If your system doesn't already have one, you can find the latest RIPE Whois client at: ftp://ftp.ripe.net/ripe/tools/ripe-whois-latest.tar.gz You can read the full anouncement at: http://www.ripe.net/ripencc/pub-services/db/whois-ipv6.html Best regards, -- Can Bican Database Group RIPE NCC

3 3

Organisation object proposal
by Shane Kerr 26 Jan '03

26 Jan '03

Colleagues, Attached please find a proposal for adding the organisation object type to the RIPE Database. As always, discussion about the document can be done on this mailing list. There will be a brief presentation at the RIPE meeting next week about organisation objects. -- Shane Kerr RIPE NCC

5 4

IPv6 Whois update
by Shane Kerr 23 Jan '03

23 Jan '03

Colleagues, As you may have seen on the list, there were a few reachability problems with the new IPv6 Whois service. We believe these are configuration related, and have a workaround allowing queries to WHOIS.RIPE.NET to work while we research it further. If you have network issues with this service please e-mail <ripe-dbm(a)ripe.net>. We also have heard some problems people are having with their Whois clients giving them errors querying the RIPE Whois server. These can occur in the case that: - The Whois client has IPv6 support. - The host computer does not have working IPv6 support. The client will: 1. Get the AAAA record for WHOIS.RIPE.NET. 2. Try to connect to the IPv6 address. 3. Fail because there is no IPv6 stack/address/router/etc. If you are experiencing this problem, you may be able to fix it by enabling IPv6 on your host (so that the IPv6 queries work), disabling IPv6 *completely* on your host (so that no AAAA records are returned), or by using another Whois client. The RIPE Whois client will work in this case, and is available from our FTP site: ftp://ftp.ripe.net/tools/ripe-whois-latest.tar.gz -- Shane Kerr RIPE NCC

3 2

RE: [ipv6-wg@ripe.net] IPV6 Whois
by matthew.ford＠bt.com 23 Jan '03

23 Jan '03

I'm getting Type 1 (Unreachable) Code 1 (Administratively Prohibited) messages back from 2001:7f8:1::a500:3333:1 - luckily the client falls back to IPv4 and that works just fine ;-) Mat. > -----Original Message----- > From: Pim van Pelt [mailto:pim@ipng.nl] > Sent: 23 January 2003 14:17 > To: ripe-dbm(a)ripe.net > Cc: db-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg(a)ripe.net] IPV6 Whois > > > | We are happy to announce the availability of RIPE Whois > servers on IPv6 > | network. It is now possible to query whois.ripe.net and > test-whois.ripe.net > | from an IPv6 host, using an IPv6 enabled whois client. If > your system doesn't > | already have one, you can find the latest RIPE Whois client at: > Hi Can, > > I cannot reach the server from AS12859, nor from AS8954. > > --- whois.ripe.net ping6 statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > > A traceroute from me (2001:7b8:3:17:202:b3ff:fe10:d926) to you gives: > 1 dapje-gw.ipv6.network.bit.nl 0.383 ms 0.286 ms 0.269 ms > 2 jun1.telecity.ipv6.network.bit.nl 1.537 ms 1.552 ms 1.505 ms > 3 nikipv6.ripe.net 3.378 ms 3.035 ms 3.111 ms > 4 nikipv6.ripe.net 4.432 ms !P 3.248 ms !P 3.288 ms !P > > And telnetting to port 43 of whois.ripe.net does not do much: > $ telnet 2001:610:240:0:193::135 whois > Trying 2001:610:240:0:193::135... > ^C > > Please advise. > -- > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim(a)ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- > >

1 0

RRCC scripts beta release
by DB-News 23 Jan '03

23 Jan '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the beta release of RRCC scripts. Routing Registry Consistency Check, or RRCC project had already its web interface, where you can check the accuracy of your data in the RIPE Routing Registry and Whois Database. Per-maintainer reports are also available as in an e-mail interface. For more information, please visit http://www.ripe.net/rrcc/ . Now you can build you own RRCC database yourself, using RRCC scripts, which you can find at ftp://ftp.ripe.net/ripe/dbase/software/RRCC-0.2.tar.gz Using these scripts, you can check the consistency of other routing registries as well. Please contact rrcc(a)ripe.net for any comments. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

draft agenda (v1), for DB-WG meeting, RIPE 44, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Jan '03

22 Jan '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st, very preliminary, draft: Proposed Agenda for the DB-WG Meeting at RIPE 44 in Amsterdam, NL. For the moment this is pretty much "work in progress", but something has to be printed on paper. I'll add the usual "syntactic sugar" later... As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft A. Administrative stuff (WW, chair) 10 min B. Action Items 15 min C. DB update (RIPE NCC, Shane K.) 20 min D ERX (Status report and future plans) (RIPE NCC) 15 min E. Organisation object proposal (RIPE NCC, Shane K.) 10 min F. status: SUB-ALLOCATED PA (Space.Net, Gert D.) 10(?) min G. reclaim: - Attribut (Space.Net, Gert D.) 10(?) min H. allowing "generated" attributes in updates (WW et.al.) 10 min I. Key Certificates to person: role: ? 10 min Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-JAN-2003 09:53:47 UTC _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

2 1

Re: contacts
by leo vegoda 20 Jan '03

20 Jan '03

Dear Mouse, You are correct in stating that the RIPE NCC does not manage the contact information stored in the RIPE Database. Contact information is currently published in "person:" or "role:" objects managed by database users. The RIPE NCC and other database users reference contact information from various objects describing networks. The current design allows the people publishing the contact data to update it independently from the people publishing the network objects that reference it. It should also be noted that the "e-mail" attribute is optional for the "person:" object in the current database specification. The RIPE NCC takes direction from consensus reached within the RIPE community. If you would like to bring about a change then please bring a proposal to the mailing list of the appropriate working group. Information about RIPE working groups may be found at: <http://www.ripe.net/ripe/wg/index.html> It may also be possible to raise a proposal during a working group session at RIPE 44 next week. RIPE 44 meeting details are available from our web site at: <http://www.ripe.net/ripe/meetings/current/ripe-44/> Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

Contacts
by der Mouse 18 Jan '03

18 Jan '03

I'm not sure this is the right place for this, but if not, perhaps someone can point me at the right place. I previously raised the issue with ncc(a)ripe.net and the person dealing with it there pointed me here, among other places. When dealing with net-abuse, I have occasion to look up addresses in RIPE's database, to contact people responsible for the relevant netblock. Mostly this is unremarkable, but sometimes the contact address bounces. In this case, I normally write to the contact for the next larger containing netblock, but when that's the RIPE, that doesn't work (the contact address for RIPE's netblocks is one which doesn't accept mail from the world at large - or at least is documented as such; I don't recall trying it recently). So I was reporting such broken contact addresses to ncc@. But the person there (signing with the name Yvette Vermeer) tells me that ncc@ is not the correct place to send them. She (I assume "Yvette" is "she") referred me to two lists, of which this is one. Presumably _somewhere_ at RIPE there is _someone_ to whom such things should be addressed; like any assigning authority, RIPE has responsibility concomitant with its authority, in particular to make sure its assignees behave themselves - such as by maintaining correct contact info. But it seems to be difficult to find whom to report such outdated contacts to. I've been lurking here for a little while, and this doesn't look like the right place to send such notifications; this appears to be more operational than policy. But perhaps I'm wrong, or perhaps someone here can tell me where I *should* send such notifications; I'm going to exhaust all the leads I can find at RIPE before going upstairs about this. I don't like to kick it even far up as RIPE (I wouldn't except that the invalid contact addresses in question are direct RIPE assignees) and I really don't want to have to go even further. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

1 0

Ref: Agenda points for the db-wg session (call for...)
by Wilfried Woeber, UniVie/ACOnet 17 Jan '03

17 Jan '03

Dear DB-WG! The RIPE NCC has already submitted items for the Jan 2003 DB-WG meeting's draft agenda. If anyone wants to propose issues/topics/items to be included, please sumbit them _asap_. I'll review the list of open actions and the minutes to complement the set of items from my end during the weekend. Regards, 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

Updated proposal for clean-up of references by name
by Engin Gunduz 16 Jan '03

16 Jan '03

[Apologies for duplicate messages] Dear Colleagues, I'm attaching the updated proposal for automatically cleaning up the references by name in RIPE Whois Database. We have incorporated Janos's suggestions to the proposal. If no more comments come, we plan to apply the procedure described in the proposal in the first half of January, 2003. The operation should not take more than a day. We will notify the community about the actual date of the operation. Regards, Engin Gunduz ____________________________ RIPE NCC Database Group -------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database Motivation: References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software. Classification of the inconsistencies we need to solve and proposed solutions: 1. Objects that refer to a person or role object by name. a. There is only one object with this name. 1. The referring inconsistent object is not maintained, or the maintainers of referring inconsistent object and the person/role object with this name are the same. Solution: Update the referring inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. The referring object is maintained, and the maintainers are different from the maintainers of the object with the referred name (If the latter object is not maintained, then the maintainers are by definition different.) Solution: Create a role object with this name. It will list the role or person object with this name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. Protect it with the inconsistent object's maintainer(s). c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Protect it with the inconsistent object's maintainer(s). Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Protect it with inconsistent object's maintainer(s). Then update the inconsistent object to refer to the NIC handle of this new place holder person object. In each case an object is updated, or created, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates). Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.

1 2

RE: [lir-wg] should aut-num object for IPv4 & IPv6 be the same?
by adrian.pauling＠bt.com 15 Jan '03

15 Jan '03

we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 address assignments from IPv4. Is the question should different 'peering-set' 'route' objects etc reflect different peerings for IPv6 from IPv4 that an assigned AS can have? This scenario is real as I can easily give a current (enterprise LIR) example. Regards, Adrian F Pauling BT Ignite Solutions

2 1

Implementing additional IPV4 Table into RIPEDB-Software (local use only)
by Arnd Vehling 08 Jan '03

08 Jan '03

Hello, i need to introduce a new IP V4 Table into the current release of the ripe-db software for a local project at Cable&Wireles. The best starting point for impletenting this is probably the definition of the current ipv4 definition of "inetnum" in attributes.xml. Befor i go ahead and start reading through tons of sourcecode, especially the one used for radix-tree operations, i thought i might ask here if someone has any general tips on what to change/not to change. Comment on the current definition if the inetnum object would also be of great help to me. I.e. which attributes to copy and which need to be changed etc. best regards, Arnd Vehling -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212

1 0

ANNOUNCEMENT: ROUTING REGISTRY TRAINING COURSES
by RIPE NCC Training 20 Dec '02

20 Dec '02

Dear colleagues, [apologies for duplicate postings] As a new service to its members the RIPE NCC offers the "Routing Registry Training Courses". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using RPSL (Routing Policy Specification Language) and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course, it will: - NOT teach the basics of routing. - NOT describe how to receive Internet resources from the RIPE NCC, nor how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. hostmasters) . It is assumed that all attendees will be familiar with BGP routing and with the RIPE DB (creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with: - Working Ethernet card, - 3 meters of Ethernet cable, - Secure connection client, - Web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership contribution. More information about the Routing Registry Training Courses can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this email and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the "Routing Registry Training Course" will not be an authoritative contact persons for their LIR, therefore will be refused by the course registration "robot". In order to be admitted to the course, confirmation email need to be send to <training(a)ripe.net> . Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ----------------------------------------------------------------------- COURSE DATES AND VENUES ======================== Date: Friday 24th Janaury 2003 Time: 0900 - 1700 Location: Amsterdam, Netherlands AND: Date: Wednesday 12th March 2003 Time: 0900 - 1700 Location: London, United Kingdom ------------------------------------------------------------------------ REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The Course you plan to attend (date and location) # COURSE [ ] %END

2 2

Proposal: key-cert update procedure change
by Dmitry Morozovsky 17 Dec '02

17 Dec '02

Dear colleagues, changing today our key-cert objects, I'd encounter a bit of inconvenience: one can't cut'n'paste key-cert object from whois request: [s]he should manually delete method/owner/fingerpr attributes. My suggestion is: if one of r/o attributes exists in the object processed, DB should check whether auto-computed value of the attribute matches supplied value; - if yes, no error/warning should be produced - if no -- it should of course be reported; I think, it's up to the community to decide whether this condition should be treated as error or simply as warning. I think, the same procedure should be also applied to other de-facto read-only attributes, such as person name in person object. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

2 2

Re: [db-wg] Proposal for automated clean-up of references by name
by Janos Zsako 05 Dec '02

05 Dec '02

> From db-wg-admin(a)ripe.net Thu Dec 5 11:08:46 2002 > From: Gert Doering <gert(a)space.net> > On Thu, Dec 05, 2002 at 10:42:53AM +0100, Engin Gunduz wrote: > > We have prepared a proposal to automatically clean-up references > > by name and other invalid references in RIPE Whois Database. > > I like the proposal. Go ahead! Yes, I agree too. > (Yes, it will potentially create lots of "ugly looking" objects - but > the situation right now, where you're not able to delete person objects > because they are locked by a reference-by-name, is much worse) I have one question though: who will be the maintainer of the new "ugly" object created? I have the feeling it could/should be the maintainer of the object that will reference it. Janos

1 0

Proposal for automated clean-up of references by name
by Engin Gunduz 05 Dec '02

05 Dec '02

[Apologies for duplicate messages] Dear Colleagues, We have prepared a proposal to automatically clean-up references by name and other invalid references in RIPE Whois Database. The proposal aims at fixing objects like (as an hypothetical example): inetnum: 58.210.0.0 - 58.210.255.255 netname: EXAMPLE-OBJECT descr: Example inconsistent object country: EU admin-c: Engin Gunduz tech-c: Engin Gunduz status: ASSIGNED PA mnt-by: RIPE-NCC-NONE-MNT changed: engin(a)ripe.net 19940508 source: RIPE Note that in admin-c and tech-c attributes there are names, instead of NIC handles, which is currently regarded as a syntax error. Such objects were introduced into RIPE Whois Database when the syntax checks were not as strict as today. There are 2114 (out of approximately 2 million references) such invalid references as of December 2nd, 2002. The proposal will affect only the objects that have invalid references where a NIC handle should be used. Please see http://www.ripe.net/db/dbconstat/ for more information on Database Consistency and Statistics Project which deals with this and other types of inconsistencies in RIPE Database. Please find our proposal below. We would like to discuss the proposal until December 20th, 2002, at which date we will sum up the discussion, and perhaps begin to implement the resulting solution. Regards, Engin Gunduz RIPE NCC Database Group -------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database Motivation: References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software. Classification of the inconsistencies we need to solve and proposed solutions: 1. Objects that refer to a person or role object by name. a. There is only one object with this name. Solution: Update the inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Then update the inconsistent object to refer to the NIC handle of this new place holder person object. In each case an object is updated, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates). Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.

2 1

Re: [lir-wg] Re: ERX of v4 address space proposal
by Andrei Robachevsky 20 Nov '02

20 Nov '02

Peter Galbavy wrote: > 192.0.0.0/8 ? > > The swamp is coming to RIPE or which poor RIR ? Our current data shows that around 753 networks will go to APNIC, 9072 stay with ARIN, 92 will go to LACNIC and 3176 to RIPE NCC. 192/8 will be processed as last and sweet piece, and statistics will be updated. > > Peter Regards, Andrei > > ----- Original Message ----- > From: "Andrei Robachevsky" <andrei(a)ripe.net> > To: <db-wg(a)ripe.net>; <lir-wg(a)ripe.net> > Sent: Wednesday, November 20, 2002 1:54 PM > Subject: [lir-wg] Re: ERX of v4 address space proposal > > > >>Dear Colleagues, >> >>You may find a list of networks (/8's) containing allocations that will >>be transferred by the ERX project at the following URL: >>http://www.ripe.net/db/erx/erx-ip/ >> >>A detailed list of which networks will be transferred, and to which RIR, >>will be posted before each /8 is transferred. A full schedule for each >>network will also be published for each /8. >> >>Regards, >> >>Andrei Robachevsky >>CTO, RIPE NCC >> >> >

1 0

ERX of v4 address space proposal
by Andrei Robachevsky 20 Nov '02

20 Nov '02

Dear Colleagues, Please find attached the proposal for the ERX of IPv4 address space for your review. This proposal was reviewed by the ERX-Taskforce that was set-up at the RIPE 43 meeting. Comments received were summarised and sent to both Database and LIR Working Group mailing lists. We would appreciate your feedback on this proposal no later than Wednesday, 13 November 2002. A timeline for this project will be issued along with final project description. Regards, Andrei Robachevsky RIPE NCC ERX of v4 address space ----------------------- INTRODUCTION When ARIN began operations, it inherited classful blocks of addresses ("legacy" space) that were issued to organisations not in ARIN's region. The Regional Internet Registries (RIRs) are co-ordinating the transfer of these records from the ARIN Database to RIPE Database or APNIC Database, as appropriate. This is based on geographic location of each resource holder. The affected records include class B networks and class C ranges, particularly those issued from 192/8. ARIN also maintains reverse delegation for all legacy address space. Once the transfer is complete, this responsibility will be distributed among the RIRs according to their respective regions. BENEFITS This will enable resource holders to maintain all their records in one database and End Users to interface with just one RIR for all database and reverse delegation matters. This effort will also help to locate address holders and recover unused or underutilised address space. IMPACT ON RESOURCE HOLDERS Entities holding legacy space to be transferred can expect the process to be largely transparent. While it will not affect network status in any way, resource holders might be required to create contact identifiers with the proper registry if they do not already exist. Queries made in WHOIS for an IP block that has been transferred to another RIR will be directed to the appropriate RIR. APPROACH The plan is to perform the transfer by /8. For each /8 the following tasks have to be performed: 1. Conflicts (contacts and description) to be resolved 2. Records and associated documentation to be transferred 3. Reverse delegation to be set up A total of 47 /8's with 8030 records have to be transferred. CONFLICTS The following types of conflicts have been identified: C1. Record exists in ARIN DB only. There is no exact matching (range wise) record in the RIPE DB. Proposal: to update internal documentation, create the record in the RIPE DB and protect with a unique generated mntner. C2. Range matches records in both ARIN and RIPE DBs. Meaning that contact and description may be different. Most cases indicate out of date information in one of the Databases, not real conflicts or attempts to hijack address space. What happened in most cases is that people started maintaining their allocation or assignement in the RIPE DB, especially since RIPE DB started to support the Routing Registry. Proposal: Notify conflicts and give time to reach consensus. After the deadline merge those who haven't responded, but _do_not_lock_ (keep the same mntner). C3.0 Record exists in the RIPE DB only. C3.1. One reason why such situation may exist is that this is a valid RIPE NCC allocation. Proposal: To preserve information in the RIPE DB. C3.2 Another situation is that the registration data are simply garbage. Proposal: Notify, give time for explanations and clean up in the end. PROCEDURE for a /8 1. Pre transfer 1.1 Initial dump is prepared for transfer by ARIN 1.2 Announcement is sent to ARIN's contacts 1.3 Reverese delegation domain space is cleaned up in the RIPE DB (reverse domain objects for which no delegation was provided are deleted) 2. Transfer 2.1 Final dump is prepared by ARIN 2.2 C1 group: database records are imported, documentation is updated, contacts are notified 2.3 C2 group: contacts (ARIN+RIPE) are asked to reach consensus. 2.4 C3.2 group: contacts are notified of possible deletion. 2.5 DNS is updated: domain objects are generated, zone (full or partial) is generated. 3. Conflict resolution 3.1 C2 group: non responding records are merged but _not_locked_. 3.2 C3.2 group: records without good reasons are deleted. -------

4 7

RADB mirror is not available over the weekend
by RIPE Database Administration 15 Nov '02

15 Nov '02

[Apologies for duplicate messages] Dear Colleagues, This is to announce that due to technical problems RADB mirror will not be available today and over the weekend on RIPE Whois Server. We hope to solve the problem and make it available again early next week. We are sorry for any inconvenience. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

Re: [lir-wg] ERX of v4 address space proposal
by Wilfried Woeber, UniVie/ACOnet 13 Nov '02

13 Nov '02

--On 5. november 2002 10:00 +0100 Berislav Todorovic <beri(a)eurorings.net> wrote: > On Mon, 4 Nov 2002, Andrei Robachevsky wrote: > >>> Please find attached the proposal for the ERX of IPv4 address space for >>> your review. > > Most legacy IPv4 address space was assigned directly by InterNIC. Should > we read that all those addresses will have "PI" status? Given the fact that those address blocks were distributed before the RIR and NIR / LIR structure was devised, those blocks are _administratively_ PI, or maybe "unspecified" which I consider equivalent (much like the very early LIR blocks :-) Technically, and wirth regard to services rendered by LIRs and RIRs to the holders of those blocks, I'd venture to guess that they should be offered a chance to "opt-in" to an existing LIR or ISP environment. > Secondly, who will provide reverse delegation and how can users of these > blocks affect reverse delegation changes? I guess auto-inaddr will not > work since it requires a valid RegID. Actually this is one of the aspects that I would have liked to tackle in the ERX-TF, unfortunately it looks like I might be too late to have those ideas discussed and considered, due to overload on my end for a while. One of the things we should have learned from the ASN relocation is that those parties are not in touch with the most recent administartive procedures imposed by the RIR (and why should they?), and they simply get mixed up when they suddenly receive messages from the NCC :-( Wilfried.

1 0