November 2002 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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 12 Nov '02

12 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

Maintenance work on RIPE Whois Server 13.11.2002
by RIPE Database Administration 12 Nov '02

12 Nov '02

[Apologies for duplicate messages] Dear Colleagues, Tomorrow, 13 November 2002 Wednesday, we plan maintenance work for the whois server. As part of the maintenance work the server software will be upgraded to improve server query performance. We plan to start around 06:30 UTC and finish the work till 10:30 UTC. During this maintenance period, - mail updates will be queued and automatically processed after the maintenance work. - webupdates and syncupdates will not be possible. - queries will be answered by our secondary server. We apologise for any inconvenience. Please contact <ripe-dbm(a)ripe.net> for any questions/ comments. Best Regards, Engin Gunduz RIPE NCC Database Group

1 0

[Internet-Drafts@ietf.org: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-01.txt]
by Stephane Bortzmeyer 08 Nov '02

08 Nov '02

1 0

Webupdates Release
by Can Bican 07 Nov '02

07 Nov '02

Dear Colleagues, Web based graphical user interface for updating the RIPE database, is released, and accessible from the following urls: For updating RIPE database: http://www.ripe.net/webupdates or https://www.ripe.net/webupdates For updating RIPE TEST database: http://www.ripe.net/webupdates-test or https://www.ripe.net/webupdates-test Webupdates provides a web based graphical user interface, with the functionality for: * Adding/deleting/editing objects, * Adding/deleting/changing the order of attributes in an object, * Providing password based authentication for updating. Since the latest prototype, the following improvements have been introduced: * A help page for using the interface has been added. * source: fields of new objects are now prefilled. * It is now possible to add new fields more easily via the '+' icon. * It is now possible to manipulate multi-line fields. * There are now links for querying the database and the copyright information. Your feedback is important to us. Please send any comments, suggestions, questions and criticisms to dbtools(a)ripe.net . We also provide help via e-mail through working hours. You can communicate your problems and questions about the service to ripe-dbm(a)ripe.net . Regards, -- Can Bican Database Software Engineer RIPE NCC

1 0

Major power outage in Amsterdam
by Andrei Robachevsky 07 Nov '02

07 Nov '02

Dear Colleagues, Due to some explosion/fire in a power sub-system a large part of Amsterdam lost power last night around 21:30 UTC, 7 November. This influenced the AMS-IX sites at SARA and NIKHEF. This also caused an outage for some of our external services, mainly ns.ripe.net and whois.ripe.net. We apologise for the inconvenience this might have caused. Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

1 0

Hierarchical authorisation failed, request forwarded to maintaine r ???
by Harald.Singer＠tesion.de 05 Nov '02

05 Nov '02

Hello, i have the problem to create a route-object for a customer of me. The customer will transfer his PI-Network (192.109.176.0/24, I´m CNSPLUS-MNT) from another ISP into my AS. And of course a mnt-routes:CNSPLUS-MNT exists. I need to create the new route-object, but i get the error: "Hierarchical authorisation failed, request forwarded to maintainer." I think I should be able to create such an object without assistance from another ISP. - As the ISP and I are using Crypt-PW I don´t want to send a mail with my password to this ISP (like the proposal from Daniel in this WG). - Some time ago i was able to create such objects without any assistance, what was the reason to change this behaviour? - The discussion some weeks ago doesn´t have any hints for a solution, or i missed it. - Do you have any proposal to create the object? Regards Harald -- Harald Singer Telefon: +49 (0)711/2021-847 tesion )) Telekommunikation Telefax: +49 (0)711/2021-93-847 Systemingenieur / CCIE #7326 Mobil: +49 (0)178/2021-847 Kriegsbergstrasse 11 Mail: harald.singer(a)tesion.de D-70174 Stuttgart Web: http://www.tesion.de

4 6