- db-wg - mailman.ripe.net

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 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

Hierarchical authorisation failed, request forwarded to maintaine r ???
by Marcus.Ruchti＠colt.de 05 Nov '02

05 Nov '02

Hi all, can somebody tell me why this update failed? inet-num maintainer is NONE and AS maintainer is ours ! This is an ARIN /16 network, but the /22 part of it is announced in the RIPE region.. thanks for your help!! Marcus Ruchti New FAILED: [route] 143.58.120.0/22 Hierarchical authorisation failed, request forwarded to maintainer. route: 143.58.120.0/22 descr: MAYER, BROWN, ROWE & MAW GAEDERTZ descr: ***routed per request*** origin: AS8220 mnt-by: DE-COLT-MNT changed: markb(a)de.colt.net 20020813 source: RIPE inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: NL admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT changed: bitbucket(a)ripe.net 20010529 changed: bitbucket(a)ripe.net 20020625 source: RIPE route: 143.58.120.0/22 descr: MBRG-FFM origin: AS3320 mnt-by: DTAG-RR changed: mbt(a)nic.dtag.de 20020619 source: RIPE route: 143.58.120.0/23 descr: MBRG-FFM origin: AS8354 notify: info(a)twinwave.net mnt-by: TWINWAVE-MNT changed: g.cipollone(a)twinwave.net 20020417 source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. e-mail: bitbucket(a)ripe.net admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT changed: bitbucket(a)ripe.net 20010411 source: RIPE Marcus Ruchti Internet Systemingenieur mailto:marcus.ruchti@colt.de COLT TELECOM GmbH Herriotstr. 4 D-60528 Frankfurt Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350

5 10

RE: Hierarchical authorisation failed, request forwarded to maint aine r ???
by Koepp, Karsten 05 Nov '02

05 Nov '02

Hi Harald, The database checks for matching and less specific routes first. If such a route exists (that's the case here), mnt-routes is required in this route object. And the mntners in the inetnum are being ignored. There was a lenghty discussion about the reasons of this procedure. I don't find that appropriate but maybe others can summarize why not to check the inetnum first. The outcome for me is, that whenever you want to give mnt-routes to somebody else, only do it in a route with your own AS as origin, but that's not applicable for PI. Regards Karsten > -----Original Message----- > From: Harald.Singer(a)tesion.de [mailto:Harald.Singer@tesion.de] > Sent: Monday, November 04, 2002 5:59 PM > To: db-wg(a)ripe.net > Subject: Hierarchical authorisation failed, request forwarded to > maintaine r ??? > > > 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 >

1 0

IRT object and authentication schemes
by Havard Eidnes 31 Oct '02

31 Oct '02

Hi, someone's prodded me wrt. the IRT object registration. This finally made me take a closer look at the available documentation defining this object type. I have one question (well, I may have more, but this one is the most important one, I think): In section 5 of http://www.ripe.net/ripe/docs/irt-object.html I find the following text: When adding a reference to an irt object the update of an inet[6]num should pass the following authorisation checks: * from the irt object itself as specified in one of the "auth:" attribute * from any of the mntner objects that protect the inet[6]num object (i.e. referenced using "mnt-by:" attribute). Is there a logical AND between these two items? (I think there is, but it really ought to be said explicitly, and the "should pass" phrase should be replaced by "must pass both of".) This is pretty crucial when evaluating what should be registered in the IRT object, as unwise choices (no overlap between irt auth: and mntnr auth:) on this front will at best make it very cumbersome to add IRT references to inetnum / inet6num objects, requiring nested signatures (I wonder, does the RIPE DB support that?). Oh, yes, I also think the IRT definition document needs to say a few words about what specific roles the admin-c and tech-c of an IRT object is supposed to fill. Regards, - Håvard

2 1

Summary of ERX-TF discussion
by leo vegoda 29 Oct '02

29 Oct '02

Dear Colleagues, As promised, here is a summary of the short discussion had on the <erx-tf(a)ripe.net> mailing list over the last few weeks. There have been about 15 messages in total. On 10 October we published the RIPE NCC's proposed ERX process for IPv4 to the Task Force. There were two technical queries: a request for confirmation that all contacts in both databases be e-mailed. Also, there was a request for confirmation on how reverse delegations would be handled. Substantive issues included a question on how early registrations would be handled from a policy point of view. The RIPE NCC confirmed that in the past, the majority of registrants have agreed to meet the current policy requirements for registration. However, we also noted that previous registrations have tended to be done for organisations who place a value on registration data. It was argued that the policy issues were less important than the accuracy of the registration data transferred/updated. No other issues on the transfer process were raised. It appears that the Task Force is happy with the proposed transfer process. As such, we would like to publish the proposed process in the next few days. Regards, -- leo vegoda RIPE NCC Registration Services

1 0

Improved Query Processing on RIPE Database Serve
by RIPE Database Administration 24 Oct '02

24 Oct '02

[ Apologies for multiple copies. ] Colleagues, Whois query processing for the RIPE Database Server has been revised to be more consistent and helpful to users. In the past, the server would make a number of changes to the user query without telling the user, for example removing characters that it did not understand or truncating the query. The new implementation will perform exactly the query the user requested, if possible, and give errors when not. Warnings are now returned where appropriate. A full description of the changes may be found here: http://www.ripe.net/db/whois-query-2002.html In general, all correct queries will provide exactly the same results as on the previous version of the server. If you have any questions please send them to <ripe-dbm(a)ripe.net>. Suggestions may be sent to <ripe-dbm(a)ripe.net>, or discussed on the RIPE Database working group mailing list, details of which may be found here: http://www.ripe.net/ripe/wg/db/index.html -- Shane Kerr RIPE NCC

1 0

[Ted.Hardie@nominum.com: [Ietf-not43] Working Group Last Call: draft-ietf-crisp-requirements-01.txt]
by Stephane Bortzmeyer 16 Oct '02

16 Oct '02

This is also for address registries like RIPE-NCC so I believe everybody should read this post-whois document and comment before the Atlanta meeting.

1 0

RE: FAILED update.
by Pieterjan d'Hertog 14 Oct '02

14 Oct '02

> > -----Mensaje original----- > > De: Iglesias Fuente, Jesus > > Enviado el: viernes 11 de octubre de 2002 13:09 > > Para: 'auto-rpsl(a)ripe.net' > > Asunto: longack > > > > password: 7djsfy25ddn > > Please change your update password :-) --- Pieterjan d'Hertog, Senior Network Engineer Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels Phone +3227061311 Fax +3227061150 http://www.skynet.be PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E

1 0

Re: NCC#2002102136 RV: FAILED update.
by RIPE Database Administration 14 Oct '02

14 Oct '02

Dear Jesus Iglesias, [Please send any operational problems/doubts with the RIPE database to ripe-dbm(a)ripe.net , this is the best address to have your doubts answered]. The failure of your update is related to the fact that you have sent your object quoted: > as-set: AS-BTTEL > descr: BT Telecomunicaciones customers > members: AS8903 > ... Please don't quote the objects, ie send like as-set: AS-BTTEL descr: BT Telecomunicaciones customers members: AS8903 ... Also, we recommend never to send your password in the clean in mail messages, especially to public mailing lists. If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Tiago Antao ____________________________ RIPE Database Administration. Original message follows: ------------------------ > Hello, > Can anyone tell me why did this update fail? > The robot answered: > > Update FAILED: Syntax error in object > ***Error: Error with class attribute, class invalid > > Thanks for your help ! > Regards. > > _________________________________ > Jes�s Iglesias Fuente > IP Platforms & Services (Planning) > BT Ignite Spain > jesus.iglesias(a)ignite.com > Phone: (+34) 91.270.62.14 > Fax: (+34) 91.270.63.10 > _____________________________________________ > > > -----Mensaje original----- > De: Iglesias Fuente, Jesus > Enviado el: viernes 11 de octubre de 2002 13:09 > Para: 'auto-rpsl(a)ripe.net' > Asunto: longack > > password: *********************** > > as-set: AS-BTTEL > descr: BT Telecomunicaciones customers > members: AS8903 > members: AS3324, AS21025 > members: AS12334, AS20784 > members: AS12356, AS12636 > members: AS8239, AS12430 > members: AS12845, AS21268 > members: AS9192, AS13066 > members: AS13143, AS15734 > members: AS12946, AS15369 > members: AS15912, AS15937 > members: AS15963, AS16373 > members: AS16203, AS13205 > members: AS20815, AS20944 > members: AS16371, AS21368 > members: AS21193, AS20718 > members: AS20760, AS20607 > members: AS24830, AS21181 > members: AS15919, AS25267 > remarks: BT Telecomunicaciones customers ASs > tech-c: BTT2-RIPE > admin-c: EL729-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > > > aut-num: AS8903 > as-name: BT > descr: BT Tel AS 1 > import: from AS701 action pref=100; accept ANY > import: from AS5400 action pref=100; accept ANY > import: from AS3561 action pref=100; accept ANY > import: from AS2856 action pref=100; accept ANY > import: from AS6895 action pref=100; accept AS6895 > import: from AS3262 action pref=100; accept AS3262 > import: from AS8761 action pref=100; accept AS8761 > import: from AS8782 action pref=100; accept AS8782 > import: from AS8220 action pref=100; accept AS8220 > import: from AS4589 action pref=100; accept AS4589 > import: from AS12457 action pref=100; accept AS12457 > import: from AS12357 action pref=100; accept AS12357 > import: from AS6897 action pref=100; accept AS6897 > import: from AS12479 action pref=100; accept AS12479 > import: from AS12852 action pref=100; accept AS12852 > import: from AS2686 action pref=100; accept AS2686 > import: from AS3352 action pref=100; accept AS3352 > import: from AS3324 action pref=100; accept AS3324 > import: from AS2134 action pref=100; accept AS2134 > import: from AS12359 action pref=100; accept AS12359 > import: from AS3352 action pref=100; accept AS3352 > import: from AS13041 action pref=100; accept AS13041 > import: from AS12386 action pref=100; accept AS12386 > import: from AS9019 action pref=100; accept AS9019 > import: from AS5978 action pref=100; accept AS5378 > import: from AS12482 action pref=100; accept AS12482 > import: from AS9106 action pref=100; accept AS9106 > import: from AS12715 action pref=100; accept AS12715 > import: from AS702 action pref=100; accept AS702 > import: from AS3247 action pref=100; accept AS-3247 > import: from AS766 action pref=100; accept AS-766 > import: from AS3257 action pref=100; accept AS-NACAMAR > import: from AS6669 action pref=100; accept AS-BTES > import: from AS3324 action pref=100; accept AS3324 > import: from AS12334 action pref=100; accept AS12334 > import: from AS12356 action pref=100; accept AS12356 > import: from AS8239 action pref=100; accept AS8239 > import: from AS12430 action pref=100; accept AS12430 > import: from AS12636 action pref=100; accept AS12636 > import: from AS12845 action pref=100; accept AS12845 > import: from AS12946 action pref=100; accept AS12946 > import: from AS9192 action pref=100; accept AS9192 > import: from AS13066 action pref=100; accept AS13066 > import: from AS13143 action pref=100; accept AS13143 > import: from AS15369 action pref=100; accept AS15369 > import: from AS15734 action pref=100; accept AS15734 > import: from AS15912 action pref=100; accept AS15912 > import: from AS15937 action pref=100; accept AS15937 > import: from AS15963 action pref=100; accept AS15963 > import: from AS16373 action pref=100; accept AS16373 > import: from AS16203 action pref=100; accept AS16203 > import: from AS13205 action pref=100; accept AS13205 > import: from AS21025 action pref=100; accept AS21025 > import: from AS20815 action pref=100; accept AS20815 > import: from AS20784 action pref=100; accept AS20784 > import: from AS20944 action pref=100; accept AS20944 > import: from AS16371 action pref=100; accept AS16371 > import: from AS21368 action pref=100; accept AS21368 > import: from AS21268 action pref=100; accept AS21268 > import: from AS21193 action pref=100; accept AS21193 > import: from AS20718 action pref=100; accept AS20718 > import: from AS20607 action pref=100; accept AS20607 > import: from AS20760 action pref=100; accept AS20760 > import: from AS24830 action pref=100; accept AS24830 > import: from AS21181 action pref=100; accept AS21181 > import: from AS15919 action pref=100; accept AS15919 > import: from AS25267 action pref=100; accept AS25267 > export: to AS701 announce AS-BTTEL > export: to AS5400 announce AS-BTTEL > export: to AS3561 announce AS-BTTEL > export: to AS2856 announce AS-BTTEL > export: to AS6669 announce AS-BTTEL AS-BTTELESPANIX AS-BTTELCATNIX > export: to AS2134 announce AS-BTTEL AS-BTES > export: to AS2686 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS3324 announce AS-BTTEL AS-BTES > export: to AS3352 announce AS-BTTEL AS-BTES > export: to AS6895 announce AS-BTTEL AS-BTES > export: to AS6897 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS8220 announce AS-BTTEL AS-BTES > export: to AS4589 announce AS-BTTEL AS-BTES > export: to AS12457 announce AS-BTTEL AS-BTES > export: to AS12357 announce AS-BTTEL AS-BTES > export: to AS12479 announce AS-BTTEL AS-BTES > export: to AS12359 announce AS-BTTEL AS-BTES > export: to AS8782 announce AS-BTTEL AS-BTES > export: to AS12852 announce AS-BTTEL AS-BTES > export: to AS13041 announce AS-BTTEL AS-BTES > export: to AS12386 announce AS-BTTEL AS-BTES > export: to AS9019 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS12482 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS9106 announce AS-BTTEL AS-BTES > export: to AS12715 announce AS-BTTEL AS-BTES > export: to AS5378 announce AS-BTTEL AS-BTES > export: to AS3257 announce AS-BTTEL AS-BTES > export: to AS702 announce AS-BTTEL AS-BTES > export: to AS3247 announce AS-BTTEL AS-BTES > export: to AS766 announce AS-BTTEL AS-BTES > export: to AS12334 announce ANY > export: to AS12356 announce ANY > export: to AS8239 announce ANY > export: to AS12430 announce ANY > export: to AS12636 announce ANY > export: to AS12845 announce ANY > export: to AS9192 announce ANY > export: to AS13066 announce ANY > export: to AS3324 announce ANY > export: to AS13143 announce ANY > export: to AS15734 announce ANY > export: to AS12946 announce ANY > export: to AS15369 announce ANY > export: to AS15912 announce ANY > export: to AS15937 announce ANY > export: to AS15963 announce ANY > export: to AS16373 announce ANY > export: to AS16203 announce ANY > export: to AS13205 announce ANY > export: to AS21025 announce ANY > export: to AS20815 announce ANY > export: to AS20784 announce ANY > export: to AS20944 announce ANY > export: to AS16371 announce ANY > export: to AS21368 announce ANY > export: to AS21268 announce ANY > export: to AS21193 announce ANY > export: to AS20718 announce ANY > export: to AS20607 announce ANY > export: to AS20760 announce ANY > export: to AS24830 announce ANY > export: to AS21181 announce ANY > export: to AS15919 announce ANY > export: to AS25267 announce ANY > admin-c: EL729-RIPE > tech-c: BTT2-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > ********************************************** Noticia legal Este mensaje electr�nico contiene informaci�n de BT Ignite Espa�a S.A.U. que es privada y confidencial, siendo para el uso exclusivo de la persona (s) o entidades arriba mencionadas. Si usted no es el destinatario se�alado, le informamos que cualquier divulgaci�n, copia, distribuci�n o uso de los contenidos est� prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido lo antes posible. Gracias.

1 0

RE: RV: FAILED update.
by Wilfried Woeber, UniVie/ACOnet 14 Oct '02

14 Oct '02

> Hello, > Can anyone tell me why did this update fail? > The robot answered: > ... >********************************************** >Noticia legal >Este mensaje electrónico contiene información de BT Ignite España S.A.U. que >es privada y confidencial, siendo para el uso exclusivo de la persona (s) o >entidades arriba mencionadas. Si usted no es el destinatario señalado, le >informamos que cualquier divulgación, copia, distribución o uso de los >contenidos está prohibida. Si usted ha recibido este mensaje por error, por >favor borre su contenido lo antes posible. >Gracias. Sorry, I am not dealing with mails containing legal disclaimers or privacy restrictions (regardless of the language they are written in ;-) -WW

1 0

RV: FAILED update.
by jesus.iglesias＠bt.es 14 Oct '02

14 Oct '02

> Hello, > Can anyone tell me why did this update fail? > The robot answered: > > Update FAILED: Syntax error in object > ***Error: Error with class attribute, class invalid > > Thanks for your help ! > Regards. > > _________________________________ > Jesús Iglesias Fuente > IP Platforms & Services (Planning) > BT Ignite Spain > jesus.iglesias(a)ignite.com > Phone: (+34) 91.270.62.14 > Fax: (+34) 91.270.63.10 > _____________________________________________ > > > -----Mensaje original----- > De: Iglesias Fuente, Jesus > Enviado el: viernes 11 de octubre de 2002 13:09 > Para: 'auto-rpsl(a)ripe.net' > Asunto: longack > > password: 7djsfy25ddn > > as-set: AS-BTTEL > descr: BT Telecomunicaciones customers > members: AS8903 > members: AS3324, AS21025 > members: AS12334, AS20784 > members: AS12356, AS12636 > members: AS8239, AS12430 > members: AS12845, AS21268 > members: AS9192, AS13066 > members: AS13143, AS15734 > members: AS12946, AS15369 > members: AS15912, AS15937 > members: AS15963, AS16373 > members: AS16203, AS13205 > members: AS20815, AS20944 > members: AS16371, AS21368 > members: AS21193, AS20718 > members: AS20760, AS20607 > members: AS24830, AS21181 > members: AS15919, AS25267 > remarks: BT Telecomunicaciones customers ASs > tech-c: BTT2-RIPE > admin-c: EL729-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > > > aut-num: AS8903 > as-name: BT > descr: BT Tel AS 1 > import: from AS701 action pref=100; accept ANY > import: from AS5400 action pref=100; accept ANY > import: from AS3561 action pref=100; accept ANY > import: from AS2856 action pref=100; accept ANY > import: from AS6895 action pref=100; accept AS6895 > import: from AS3262 action pref=100; accept AS3262 > import: from AS8761 action pref=100; accept AS8761 > import: from AS8782 action pref=100; accept AS8782 > import: from AS8220 action pref=100; accept AS8220 > import: from AS4589 action pref=100; accept AS4589 > import: from AS12457 action pref=100; accept AS12457 > import: from AS12357 action pref=100; accept AS12357 > import: from AS6897 action pref=100; accept AS6897 > import: from AS12479 action pref=100; accept AS12479 > import: from AS12852 action pref=100; accept AS12852 > import: from AS2686 action pref=100; accept AS2686 > import: from AS3352 action pref=100; accept AS3352 > import: from AS3324 action pref=100; accept AS3324 > import: from AS2134 action pref=100; accept AS2134 > import: from AS12359 action pref=100; accept AS12359 > import: from AS3352 action pref=100; accept AS3352 > import: from AS13041 action pref=100; accept AS13041 > import: from AS12386 action pref=100; accept AS12386 > import: from AS9019 action pref=100; accept AS9019 > import: from AS5978 action pref=100; accept AS5378 > import: from AS12482 action pref=100; accept AS12482 > import: from AS9106 action pref=100; accept AS9106 > import: from AS12715 action pref=100; accept AS12715 > import: from AS702 action pref=100; accept AS702 > import: from AS3247 action pref=100; accept AS-3247 > import: from AS766 action pref=100; accept AS-766 > import: from AS3257 action pref=100; accept AS-NACAMAR > import: from AS6669 action pref=100; accept AS-BTES > import: from AS3324 action pref=100; accept AS3324 > import: from AS12334 action pref=100; accept AS12334 > import: from AS12356 action pref=100; accept AS12356 > import: from AS8239 action pref=100; accept AS8239 > import: from AS12430 action pref=100; accept AS12430 > import: from AS12636 action pref=100; accept AS12636 > import: from AS12845 action pref=100; accept AS12845 > import: from AS12946 action pref=100; accept AS12946 > import: from AS9192 action pref=100; accept AS9192 > import: from AS13066 action pref=100; accept AS13066 > import: from AS13143 action pref=100; accept AS13143 > import: from AS15369 action pref=100; accept AS15369 > import: from AS15734 action pref=100; accept AS15734 > import: from AS15912 action pref=100; accept AS15912 > import: from AS15937 action pref=100; accept AS15937 > import: from AS15963 action pref=100; accept AS15963 > import: from AS16373 action pref=100; accept AS16373 > import: from AS16203 action pref=100; accept AS16203 > import: from AS13205 action pref=100; accept AS13205 > import: from AS21025 action pref=100; accept AS21025 > import: from AS20815 action pref=100; accept AS20815 > import: from AS20784 action pref=100; accept AS20784 > import: from AS20944 action pref=100; accept AS20944 > import: from AS16371 action pref=100; accept AS16371 > import: from AS21368 action pref=100; accept AS21368 > import: from AS21268 action pref=100; accept AS21268 > import: from AS21193 action pref=100; accept AS21193 > import: from AS20718 action pref=100; accept AS20718 > import: from AS20607 action pref=100; accept AS20607 > import: from AS20760 action pref=100; accept AS20760 > import: from AS24830 action pref=100; accept AS24830 > import: from AS21181 action pref=100; accept AS21181 > import: from AS15919 action pref=100; accept AS15919 > import: from AS25267 action pref=100; accept AS25267 > export: to AS701 announce AS-BTTEL > export: to AS5400 announce AS-BTTEL > export: to AS3561 announce AS-BTTEL > export: to AS2856 announce AS-BTTEL > export: to AS6669 announce AS-BTTEL AS-BTTELESPANIX AS-BTTELCATNIX > export: to AS2134 announce AS-BTTEL AS-BTES > export: to AS2686 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS3324 announce AS-BTTEL AS-BTES > export: to AS3352 announce AS-BTTEL AS-BTES > export: to AS6895 announce AS-BTTEL AS-BTES > export: to AS6897 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS8220 announce AS-BTTEL AS-BTES > export: to AS4589 announce AS-BTTEL AS-BTES > export: to AS12457 announce AS-BTTEL AS-BTES > export: to AS12357 announce AS-BTTEL AS-BTES > export: to AS12479 announce AS-BTTEL AS-BTES > export: to AS12359 announce AS-BTTEL AS-BTES > export: to AS8782 announce AS-BTTEL AS-BTES > export: to AS12852 announce AS-BTTEL AS-BTES > export: to AS13041 announce AS-BTTEL AS-BTES > export: to AS12386 announce AS-BTTEL AS-BTES > export: to AS9019 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS12482 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS9106 announce AS-BTTEL AS-BTES > export: to AS12715 announce AS-BTTEL AS-BTES > export: to AS5378 announce AS-BTTEL AS-BTES > export: to AS3257 announce AS-BTTEL AS-BTES > export: to AS702 announce AS-BTTEL AS-BTES > export: to AS3247 announce AS-BTTEL AS-BTES > export: to AS766 announce AS-BTTEL AS-BTES > export: to AS12334 announce ANY > export: to AS12356 announce ANY > export: to AS8239 announce ANY > export: to AS12430 announce ANY > export: to AS12636 announce ANY > export: to AS12845 announce ANY > export: to AS9192 announce ANY > export: to AS13066 announce ANY > export: to AS3324 announce ANY > export: to AS13143 announce ANY > export: to AS15734 announce ANY > export: to AS12946 announce ANY > export: to AS15369 announce ANY > export: to AS15912 announce ANY > export: to AS15937 announce ANY > export: to AS15963 announce ANY > export: to AS16373 announce ANY > export: to AS16203 announce ANY > export: to AS13205 announce ANY > export: to AS21025 announce ANY > export: to AS20815 announce ANY > export: to AS20784 announce ANY > export: to AS20944 announce ANY > export: to AS16371 announce ANY > export: to AS21368 announce ANY > export: to AS21268 announce ANY > export: to AS21193 announce ANY > export: to AS20718 announce ANY > export: to AS20607 announce ANY > export: to AS20760 announce ANY > export: to AS24830 announce ANY > export: to AS21181 announce ANY > export: to AS15919 announce ANY > export: to AS25267 announce ANY > admin-c: EL729-RIPE > tech-c: BTT2-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > ********************************************** Noticia legal Este mensaje electrónico contiene información de BT Ignite España S.A.U. que es privada y confidencial, siendo para el uso exclusivo de la persona (s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido lo antes posible. Gracias.

1 0

AW: Hierarchical authorisation failed, request forwarded to maint aine r ???
by Marcus.Ruchti＠colt.de 14 Oct '02

14 Oct '02

yes, I 've made the same experiences! 2 route objects, 2 different AS, same precision (/22). In the the RIPE DB are some of these examples... Marcus Ruchti -----Ursprüngliche Nachricht----- Von: Gert Doering [mailto:gert@space.net] Gesendet am: Montag, 14. Oktober 2002 10:38 An: Shane Kerr Cc: Ruchti, Marcus; db-wg(a)ripe.net Betreff: Re: Hierarchical authorisation failed, request forwarded to maintaine r ??? Hi, On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote: > Most objects are uniquely identified by the first attribute, or > "route:" in this case. However, you must include the "origin:" > attribute for a route object. So this is: > > route: 143.58.120.0/22 > origin: AS3320 > > The object you are trying to create will be: > > route: 143.58.120.0/22 > origin: AS8220 Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS. So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Mailing List Software Migration
by RIPE NCC WebMaster 10 Oct '02

10 Oct '02

Dear Mailing List Subscriber, The RIPE NCC will change its mailing list software from "majordomo" to "mailman" on 17 October 2002. The new mailing list software will give users more options to manage their subscriptions to the RIPE and RIPE NCC mailing lists. Additionally, this change is being made to ensure stability and continuity of mailing list management and archiving. The new mailing list software will give users a number of options using a web interface: - Subscribing and Unsubscribing to mailing lists - Reviewing general information about the mailing lists - Viewing subscriptions to mailing lists - Temporarily disabling mail delivery - Choosing between regular and digests of mailing list postings - Acknowledgements to postings The web interface will be located at the following URL: http://www.ripe.net/mailman/ As well as using the web interface, mailing list users can manage their subscription and retrieve information by using an e-mail client. Further details on this are available at the above URL. Please note that if mailing list users are already subscribed to one or more mailing lists, they do not have to take any action. Messages can still be sent to the regular mailing lists addresses and subscriptions will not have to be re-confirmed. If you have any questions about this migration, please feel free to send an e-mail to <webmaster(a)ripe.net> Kind Regards, Jeroen Bet RIPE NCC Mailing List Moderation

1 0

RIPE Whois Server version 3.1.1
by RIPE Database Administration 09 Oct '02

09 Oct '02

Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of Version 3.1.1 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - MD5-PW authentication added. - IPv6 status changed to comply with new RIPE policy. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.1.1 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.1.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.1-nocxref.tar.gz A diff for the 3.1.1 "nocxref" version is also available, if you already have 3.1.0 and would prefer to patch that version instead, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.1.0-nocxref-3.1.1… The client has been updated, with a minor performance increase: ftp://ftp.ripe.net/tools/ripe-whois-3.1.1.tar.gz The Object Parsing Library (OPL) standalone source has also been updated, and is identical to the library used with the release. In the future, we will be releasing the OPL at the same time as the RIPE Whois server to keep them synchronised: ftp://ftp.ripe.net/ripe/dbase/software/RPSL-OL-3.1.1.tar.gz If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net> -- Shane Kerr RIPE NCC

3 6

creation of taskforce to support the ERX project (early registration xfer)
by Wilfried Woeber, UniVie/ACOnet 04 Oct '02

04 Oct '02

Dear participants in the DB and LIR WGs, as discussed and agreed in the DB-WG in Rhodes, and reported to the plenary, this is the "heads up" for the creation of a TaskForce (ERX-TF) to help in planning and test-driving the procedures and activities required to *most efficiently* perform the transfer of "early registrations" (sometimes also referred to as "legacy" IPv4 address space) from the ARIN DB to the RIPE DB.. [ For background information about the ERX Project please refer to the RIPE / RIPE NCC web pages. ] The proposed name of the TaskForce is "ERX-TF" . The preliminary and initial description of the activity is as follows: "The goal of the TF is to develop a proposal to the community of the transfer of early registration IPv4 address records (ERX) from ARIN to the RIPE NCC." For a start, I'd expect the TF to review the lessons learned from the transfer of AS Number Objects, and to investigate new or different issues with the already agreed transfer of IPv4 address space objects. The necessary next steps are 1) to ask the bigger community, by way of the mailing lists, whether there are any objections against the creation of the TF 2) to work on a refinement of the mandate, tasks to perform, and the expected results 3) to agree on a schedule, set of participants and to find a coordinator. Most of the work should be done by way of exchanging email amongst the TF Partcipants. Following up on expressions of interest as received during the RIPE43 WG session, an initial list of individuals would be put onto the mailing list. [ please see at the bottom of this mail ] Of course, if you are no longer interested - just let us know. Also, if you _are_ interested to join in - but did not or could not indicate your interest in Rhodes, please get back to us asap! Assuming that there would not be a major show-stopper, could I ask the NCC to follow up with any useful info (list name, draft schedule,...) to get us going as soon as possible? Cheers, Wilfried. Initial list of TF particpants: Havard Eidnes <he(a)uninett.no> Hank Nussbacher <hank(a)att.net.il> Gabriella Paolini <gabriella.paolini(a)garr.it> Kristian Rastas <kristian.rastas(a)sonera.com> Nigel Titley Ruediger Volk Wilfried Woeber <woeber(a)cc.univie.ac.at> _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 2

Draft Minutes DB-WG RIPE 43
by Nigel Titley 01 Oct '02

01 Oct '02

I'm sure I posted this set of minutes, but I can't find it on the mailing list. So here goes again. Errors and problems to me. I'll give it 2 weeks and then issue the final version. Nigel Database Working Group Meeting Minutes (Draft 1) RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR Thursday, Sept. 12, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer to take notes received from Nigel) . circulate list of participants, agenda bashing . status of minutes [ see http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html ] . All presentation slides are available on the RIPE NCC web site. B. Action Items . status of actions [AP-41.1 WW] To send list of proposed updates to IRRToolSet to mailing list for WG members to vote on. Deadline 3 weeks. Expired and superceded by AP-43.6 and AP-43.9 [AP-41.2 C&W] To send their proposal to allow referencing external objects in the DB to the mailing list for discussion. Superceded by AP-43.7 and AP-43.8 [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. Ongoing, some work done. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. Complete. IRT objects are being created (4 so far) and no problems being reported with process. [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. Ongoing, no action yet, nothing from Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. Ongoing, no action yet [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. Ongoing. Some work done. [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners using MAIL-FROM Complete. [AP-41.12 RIPE-NCC] Look at general password authentication methods Ongoing. No action yet. [AP-42.1 ALL] To check own data and correct inconsistencies if possible. Closed [AP-42.2 RIPE-NCC] To send instructions on multiple credentials to the DB working group mailing list. Complete. Instructions are now on the RIPE web site. [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow passwords and multiple level authentication schemes. [AP-42.3 Larry Blunk] To investigate the problems of multiple hashed passwords and the possibilities of embedding an ID within the hash and to submit a proposal to the working group. A proposal came from Janos to embed such information in the remarks field. C. DB update (RIPE NCC, Andrei R.) . operations report Statistics Slightly more objects (1.6M) 80,000 users on average 18q/s average, peaking to 65q/s 2 updates per second average Still some growth in unreferenced personal objects. Need garbage collection process. 70% of queries are for contact information Updates pretty average apart from spike in mntner object caused by removal of mail-from authentication Back-end problems solved. Performance issues with long queries is still to be resolved. Otherwise scaling well User support 6 support staff shared with other software projects Introduced anti-spam filter for mail to ripe-dbm (mail routed to folder) since 20th May 2002 Added ripe-dbm ticket system (shared with hostmaster) MAIL-FROM phasing out process. 1500 maintainers missed the deadline. High fax load on DB staff. Robot now in place. Developments New MD5-PW authentication scheme. 41% of maintainers are using it. New status values for intetnum6 are not now generated. DB consistency and statistics project is now generated useful data RRCC full prototype is now up and running IRRToolset. New version 4.7.3 released. Mostly bug-fixes. The database user manual "Getting Started" has been published. (Dummies guide to the RIPE Database). Real Database user's manual is being progresses IRT Document has been published (functionality and procedures) Plans Further improving of server software (Error reporting, performance, and configuration management). Support auth checks across multiple registries IPv6 and multicast support Automatic database cleanup (if object is not referenced then delete after a certain time (following nag messages to user)). There are other possibilities [AP43.1 RIPE NCC] Look at other possibilities for database cleanup. Additional user support (Documentation, Sync and Web interface) Main Events Improvements in security (MD5 and MAIL-FROM) Documentation and User support Web and syncupdate interfaces. D Web interface and Syncupdates for DB (RIPE NCC, Can Bican) Currently updates are via email Hard to automate Difficult for beginner Syncupdates allows online updates to database, web interface built on top of this TCP based Extensible, maintainable, same functionality, easy to use. Minimal client (HTTP) can be used Notifications are sent by email as usual WebUpdates is a prototype of an update client which allows adding, deleting and updating of an object. Only password authentication. Passwords are stored via cookies. No PGP authentication Multi-line attributes not properly handled Only one object may be updated in a submission All suggestions and feature requests are welcomed. http://webupdates-test.ripe.net http://syncupdates-test.ripe.net Probably one month before coming into production (syncupdates) Webupdates can be earlier, but please send comments to the db tools email address. E. Database Consistency Project Statistics (RIPE NCC, Shane) This refers to data that can be seen as incorrect merely by looking at the database itself (eg not routing inconsistencies) Changes in rules Abandoned data User error Examples Non handle admin-c Syntactic errors Missing or incorrect status attributes Unreferenced person objects Unreferenced maintainer objects CSIRT for no networks Unreferenced PGP key Also non-authoritative Data Prehistoric inetnum (non-RIPE) Objects in unprotected space Possibly unauthorized route objects Abandoned objects Unresponsive maintainers (both LIR and non-LIR) Outdated contacts Solutions Reports RRCC reports Database consistency reports Really only helpful for actively maintained objects Restrict Input Many of these checks already but will soon include integrity checks and RPSS checks Does not address current problems Revocation Allow higher level maintainer to delete objects lower in the hierarchy. (Currently can only be done by ripe-dbm). Unresponsive maintainers? Use another maintainer, or delete maintainer? Cleanups RIPE NCC implementation of WG decision Has been done in the past successfully. Discussion Normally starts on the mailing list, generating proposals which are then voted on at the RIPE meeting. Opinions Why spend a lot of resources to clean it up? It will never be completely clean? Only 5% garbage. Difference between structural problems and operational problems. Garbage can prevent the generation of accurate reverse delegation zone files, and address allocation reports. Even 5% garbage can render these useless. Registration of contact information can be really useful, even if not related to operational data. Should we be removing this data if it is useful? However, privacy issues now pertain to this data. We should also be wary of using the DB as a general key-server. F. "Early Registration Transfer" (ERX) Project (Andrei, RIPE NCC) . Introduction ASN and IP registration inherited by ARIN from Internic Pre-RIR Non-geographical . Goals and Phases Transfer of DB records and conflict resolution Transfer of associated documentation Phase 1 ASN registrations Phase 2 IPv4 registration . AS number migration ARIN only (419 ASNs) just created and protected in the RIPE DB Completed 21st August ARIN & RIPE (conflicting data, no RP) (87 ASNs) merge and lock. Resolve conflict and then unlock Completed 21st August ARIN & RIPE (with RP specifications) (177 ASNs) manual 2 week conflict resolution prior to transfer Completed 21st August 30% of notification emails bounced. Lessons Don't use August..... Often no evidence. Makes resolution very difficult in cases of dispute. Do not lock objects. They may be in use. Some people only wake up at the deadline . IP V4 migration 47 /8s to be transferred Conflicts are likely to be more complex. Transfer of DNS reverse delegations. Group 1 (ARIN only) Create and protect in the RIPE DB Group 2 (Exact match between ARIN and RIPE, except for contact and description) Resolve conflicts and then merge (do not lock) Group 3 (RIPE does not match ARIN) If NCC allocation then keep in RIPE Otherwise delete (after response time) . Discussion Thanks for the RIPE NCC from ARIN for their cooperation Human matching of records cannot necessarily be done by machine. Records that obviously match on visual inspection may not be easily matchable automatically. Two weeks (especially in August) is not enough time to resolve conflicts [AP43.3 RIPE NCC] Provide detailed action plan to the WG before implementing Phase 2. Trying to obtain authorization from contacts in the ARIN database is likely to be difficult, as in many cases the authoritative data is the RIPE database. Hence it may be necessary to extend the time for resolution of conflicts. What happens to IPv4 objects that are in an undefined state after the process? They will remain locked until the holder emerges. At which point the appropriate procedures will be invoked. Is there any chance of getting information about what IP objects will be transferred, prior to the actual transfer process? [AP43.4 RIPE NCC] To produce a list of requirements for such a list. Is there a possibility of automatically aggregating eg /24s in the ARIN database to the appropriate aggregated object in the RIPE DB? Probably not, as there don't seem to be many such objects. This will probably be a manual process. A suggestion that more resource be allocated to the IPv4 migration than was allocated to the ASN migration. [AP43.5 WW] Set up a task force to go through some test cases before hand. It should report on the mailing lists (DB and LIR) within 4 weeks. (Wilfried Woeber, Nigel Titley, Joao Luis Damas at least) Are there any requirements from the outside for target dates? No fixed date, but should get it done as quickly as possible. G. IRRToolSet Development Brainstorming (+ external refs?) . how to find out who is using what? A few people are... one at least is using a home-brew set of tools It was noted that those who are using the toolset are using it together with other tools. This may have to be taken into account. Some things are missing eg Support for zebra [AP-43.6 ALL] Those who have requirements to send to IRRToolSet(a)ripe.net What tools do people find useful? [AP-43.9 RIPE NCC] To try and track down some of the outdated references to the IRRToolset out on the web and get them corrected. . External reference Who needs it? Need at a minimum things like AS-sets which are referred to in the RFC. Need a list of things for which it makes sense and those for which it would be insane (Ruediger Volk) The status of external reference in the RPSS RFC is "out of document scope", although a possible mechanism is described. There is a clear need for this, and the C&W registry is using this syntax. It is also needed in order forms etc (and is already included in some forms from some providers). The RPSS working group needs waking up to properly resolve this issue. Should the DB be prepared to accept this syntax? No real performance issues (Andrei) and not a real problem. The RPSL-dist informal proposal suggests a new "registry" object. [AP-43.7 Ruediger Volk] To produce a short report on what would be useful and how to start. [AP-43.8 RIPE NCC] To investigate how much effort would be required to add this functionality to the RIPE DB. Y. Input from other WGs . None Z. AOB: . Organi[sz]ation object proposal Examples would be a local registry which could be well described in such an object. . IRT object There are only 4 such objects. However no one has had problems creating

1 0