- db-wg - mailman.ripe.net

Planned maintenance
by RIPE Database Administration 07 Feb '01

07 Feb '01

Dear colleagues, To improve the quality of our service, we decided to report on reindexing of our database, and other maintenance issues. We will continue to do this if the community thinks this is a good idea. Next weekend, 10-11 February 2001, RIPE NCC will reindex the person objects in RIPE whois database. This is a usual maintenance practice, performed once every three weeks. The reindexing will start at 2:00am Saturday, and is expected to last around 40 hours, due to the very high number of person objects in our database. During the reindexing, it won't be possible to update, delete, or create person objects. The messages containing person objects will be queued. Any person object in an update message to <auto-dbm(a)ripe.net> will cause the whole update message to be blocked until the reindexing process finishes. Thus, we suggest our users not to put person objects in a message that contains other types of objects. Reindexing will not be needed in version 3 of our database software. You can see a schedule for this and other maintainance issues at: http://www.ripe.net/ripencc/pub-services/db/DBstatus.html This page will be updated regularly. We apologize for any inconvenience the maintenance may cause. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Modifying 'person:' objects
by Carsten Schiefner 05 Feb '01

05 Feb '01

Colleagues, as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list. What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data changed manually. I consider this as not very efficient. During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma. What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...). Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so... Any comments will be appreciated. Best regards, -C.

3 3

RE: Modifying 'person:' objects
by Wilfried Woeber, UniVie/ACOnet 05 Feb '01

05 Feb '01

>Are you proposing to change the RIPE-181 version of RIPE-DB software >(v2.x) or the upcoming RPSL version of RIPE-DB software (v3.x) ? Based on - the fact that handling of person: and role: objects is not going to change too much due to RPSL or DB-SW V3, and - the fact that we have agreed on "DateX" to be April 23, 2001, and we still have to discuss the merits of Karsten's proposal, I think the implementation would only affect Version 3. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Migration issues: route creation
by Andrei Robachevsky 05 Feb '01

05 Feb '01

Dear Colleagues, You may know that the new version of the RIPE database (v3.0) also supports Routing Policy Security System (RFC2725). One of the implications is that this may prevent registrations of "foreign" routes in the RIPE IRR (that is routes from non RIPE address space and/or non RIPE ASN). According to RFC2725, creation of a route object should be authorized by the "owner" of the respective address space or aggregate route and by the "owner" of the ASN that is specified as route origin. In case of absence of the corresponding objects, creation of the route object will fail. The creation of the corresponding "foreign" objects will not be as easy in the new version as it is in the current one. The ASN space will be protected by as-block object, and IP address space by corresponding top level inetnum object. This makes registration of "foreign" routes almost impossible, which affects current practice when an IPS requests that clients' routes should be registered in the RIPE IRR. Possible solutions to this problem are: 1. Send such registration requests to the Database Administration (ripe-dbm) who will perform registration by overriding security (and performing necessary checks before). This puts additional load on ripe-dbm and creates duplicate objects in the RIPE database and "foreign" IRR. 2. Do not allow such registrations. In this case some ISPs will need to change their peering policy and accept routing information from a "foreign" IRR. Your comments and suggestions are highly appreciated. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: Modifying 'person:' objects
by Lu, Ping 30 Jan '01

30 Jan '01

Are you proposing to change the RIPE-181 version of RIPE-DB software (v2.x) or the upcoming RPSL version of RIPE-DB software (v3.x) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Carsten Schiefner [mailto:carsten.schiefner@tcpip-gmbh.de] > Sent: Monday, January 29, 2001 8:03 AM > To: db-wg(a)ripe.net > Subject: Modifying 'person:' objects > > > Colleagues, > > as a follow-up of the short discussion we have had last week > during RIPE > 38 I'd like to continue this discussion in the appropriate forum, the > db-wg mailing list. > > What from time to time really annoys me is the fact that you cannot > change a person's name (necessary due to misspellings etc.) that is > already referenced because the person's name together with the NIC > handle is the primary key. You cannot delete and re-enter it either > because it's already referenced. The only way to go is to > send an email > to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data > changed manually. I consider this as not very efficient. > > During the meeting we were told by Joao and/or Andrej that basically > there is no further need to have person's name _AND_ NIC handle as the > primary key, only the NIC handle would be enough. Anyhow, I wouldn't > like to touch this pragma. > > What I would like to propose is a second "pseudo" attribute > in addition > to 'delete:' - having no documentation purpose but functionality: the > "I really know what I am doing right at the moment" attribute > ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above > mentioned db pragma and forces a change in a person's name > (so 'force:' > migt be better...). > > Where I haven't made up my mind yet is the question whether > this always > should apply or only in thoses cases when a person object is > maintainer > protected. There might be further cases I have not in mind at > all at the > moment - so... > > Any comments will be appreciated. > > Best regards, > > -C. > > >

1 0

CERT/IRT object in the RIPE database
by Gorazd Bozic 23 Jan '01

23 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Dear RIPE DB-WG team, I would like to inform you that the proposal for the CERT/IRT object in the RIPE database was presented by Wilfried Woeber at the TERENA TF-CSIRT meeting last Wednesday in Barcelona. After a discussion and proposed minor changes, the participants at the meeting expressed their strong support for the proposed new object. The purpose of the TERENA CSIRT Coordination activity in the frame of TF-CSIRT is to encourage and support the cooperation between CSIRTs in Europe. More information on TF-CSIRT is available at http://www.terena.nl/cert/ Best regards, Gorazd Bozic, TF-CSIRT Chairman - -- Gorazd Bozic <gorazd.bozic(a)arnes.si> ARNES SI-CERT, Jamova 39 p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 88 22, fax: +386 1 479 88 99 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOmt2mwxzg1x3uI5pAQGicgQA6EBqi2jrONkYYFEHDAilLTcUbvZ13EUj DXRUG6wR4S0avygROM8WhYu63U08tAkQ8NUUv+rPXof/jToMNHqLiFx05bTgnRcK 53Dsue+m/XWxA1/IO6ju9Ldr1b1HKzxaDXpikiEsG7y+iR3ghhMaWH4py7xmzube XgI/RGFeHoA= =9Lv9 -----END PGP SIGNATURE-----

3 2

Delays in RIPE Database updates
by RIPE Database Administration 22 Jan '01

22 Jan '01

Dear All, As some of you may have already noted, we are experiencing delays with the processing of updates in the RIPE Database. This is due to the fact that the last week-end, the reindexing of person objects took much longer than expected; in the meanwhile, no updates could be processed, so they remained blocked in the queue. As of now, the updates are being regularly processed. We want to stress the fact that your updates will be eventually processed and there is no need to resend your update messages; this will have the sole effect of adding load to the update queue. To check the current wait time for updates and other operational statistics for the RIPE Whois Database server, please see: http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html We apologize for any inconvenience this may cause or have caused. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

URGENT: Database problems?
by Berislav Todorovic 21 Jan '01

21 Jan '01

Dear RIPE NCC colleagues, I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, but can someone, please, take a look on the database update queue? Either the queue is full or the automatic email robot is broken. We sent an update of AS-KPNQWESTRO few times since Friday and no answer we got from the robot. That's 3 (three) days !!!!!!!!! Thanks! Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

2 1

Announcement: RIPE Whois Database Version 3.0beta2 released
by RIPE Database Announcements 19 Jan '01

19 Jan '01

Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact <ripe-dbm(a)ripe.net> for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC

3 2

DB-WG minutes
by Nigel Titley 19 Jan '01

19 Jan '01

Here is the final version of the DB-WG minutes. I have rolled in all comments received to date. Nigel

1 0