- db-wg - mailman.ripe.net

analysis of changed flag
by Frank Bohnsack 31 May '01

31 May '01

Dear Colleagues, As global ISP we need to mirror all important IRRs like RIPE, ARIN and APNIC. Many object are registerd in more than one IRRs. Currently we decide which object is valid based on the last 'changed' flag (Ok we could compare the complete object but it is possible to have different version on each IRR). But it seems that this flag isn't really in use ;-( Could it be an option to check this flag on each update ? cheers frank here one example ... old version: > aut-num: AS12437 > as-name: UNSPECIFIED > descr: ICSmedia GmbH > descr: Full Service Internet Provider > descr: Muenster (Germany) > import: from AS6754 > action pref=100; > accept ANY > import: from AS8638 > action pref=100; > accept AS8638 > import: from AS1270 > action pref=100; > accept ANY > export: to AS6754 > announce AS12437 > export: to AS8638 > announce AS12437 > export: to AS1270 > announce AS12437 > default: to AS6754 > action pref=100; > networks ANY > admin-c: HR29-RIPE > tech-c: HR29-RIPE > mnt-by: ICSMEDIA-MNT > changed: hostmaster(a)ripe.net 19990520 > source: RIPE last version: > aut-num: AS12437 > as-name: ICSMEDIA-DE > descr: ICSmedia GmbH > descr: Full Service Internet Provider > descr: Muenster (Germany) > import: from AS6754 > action pref=100; > accept ANY > import: from AS8638 > action pref=100; > accept AS8638 > import: from AS1270 > action pref=100; > accept ANY > import: from AS702 > action pref=100; > accept ANY > export: to AS6754 > announce AS12437 > export: to AS8638 > announce AS12437 > export: to AS1270 > announce AS12437 > export: to AS702 > announce AS12437 > default: to AS6754 > action pref=100; > networks ANY > admin-c: HI638-RIPE > tech-c: HI638-RIPE > mnt-by: ICSMEDIA-MNT > changed: hostmaster(a)ripe.net 19990520 > source: RIPE

1 0

Questions on mirroring RIPE
by Andy Linton 31 May '01

31 May '01

In preparation for getting a RIPE mirror running at APNIC, I copied a copy of the RIPE database and started the loader scripts on this. That was 73 hours ago and we're still on the first pass through. At this stage the logfile recording the load is 182592742 bytes long and the the directory holding the MySQL database is 1063916 Kbytes in size. Will this job finish within the next week, month, year...? Since we're running the RPSL code I took the snapshot from /ripe/dbase3/snapshot. Was that a good call? Would an alternative option for priming a v3 server be to make a compressed snapshot of the MySQL database and remove the need to load the raw data into the MySQL database via the server? I suspect the machine we're using is too small for the task - any recommendations on minimum configurations? Should we give up until we've got a bigger machine or RIPE staff do the promised spring clean of the data (or both)? Answers appreciated. andy

4 3

Announcement: PGPi 5.0 licences
by Andrei Robachevsky 22 May '01

22 May '01

Dear Colleagues, Following the discussion at the RIPE-39 meeting, Aril 30 - May 4 2001, the RIPE NCC will discontinue issuing licenses for PGPi 5.0 software. No licenses will be issued after June 1, 2001. There are two main reasons for such decision: 1. The PGPi 5.0 software contains several bugs that may compromise the security of the generated keys. The RIPE NCC can issue licenses only for this version of the software. 2. The v3 of the RIPE Database supports GnuPG (GNU Privacy Guard) software, which is available free of charge and is proved to be a reliable and secure software. To learn more about GnuPG software, please visit http://www.gpg.org. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 2

db-help Mailinglist
by Hank Hampel 18 May '01

18 May '01

Hi there! I just want to ask if there is going to be a db-help mailinglist to reduce the unnecessary traffic to hostmaster(a)ripe.net and to shorten the wait queue. I think this mailinglist would really be helpfull - at least if it's existence will be propagated at a prominent place (i.e. the RIPE website). Because nowadays many people tend not to actually read documentation and instead use the "easy" way of just asking questions to any mailaddress that seems suitable (and even to those not so suitable). Even so I think a FAQ and a step-by-step documentation of the "10 most frequent actions with the RIPE DB" is really a good idea I think we should also create this mailinglist - and if it's just for the sake of pointing people to the right documents. ;) So I propose, to get things going, to have something like a strawpoll/show of hands who is willing to participate on such a mailinglist. Count this mail as the first hand up. ;) Sincerely yours, Hank

2 1

route-set members
by Frank Bohnsack 17 May '01

17 May '01

Dear Colleagues, I have a simple question about route-set objects. <--RFC2622--> ... 5.2 route-set Class The attributes of the route-set class are shown in Figure 12. The route-set attribute defines the name of the set. It is an RPSL name that starts with "rs-". The members attribute lists the members of the set. The members attribute is a list of address prefixes or other route-set names. Note that, the route-set class is a set of route prefixes, not of RPSL route objects. ... </--RFC2622--> 1/ What is the reason that a route-set member can not be an aut-num or as-set object ? Because some registries allow this: route-set: RS-AS101-TO-ABILENE descr: routes that Abilene should accept from AS101 members: AS73, AS11808, AS7774, AS3807, AS13476, AS11995, AS14077, AS13476, AS11964, AS11827, 131.107.151.0/24, 131.252.0.0/16, 134.39.60.0/24, 161.55.0.0/16, 168.156.80.0/20, 168.156.96.0/19, 192.35.180.0/24, 192.46.80.0/24, 198.107.144.0/21, 198.32.40.0/24 admin-c: UW-NOC tech-c: UW-NOC mnt-by: MAINT-AS73 changed: aracine(a)cac.washington.edu 20010426 source: RADB 2/ Means the last phrase that there are no necessary is to existence of a related route object ? cheers frank

3 2

Inetnum Object
by Simeoli Enrico 17 May '01

17 May '01

Hi, I have some problem to make new registration at RIPE NCC DB from some allocated range because in the DB there is not its related inetnum object (for i.e 151.39.0.0/16). I know that this object is created by the RIPE at the first assignment, but I will already use this range because it was allocated to us by the ARIN in the past and we had made some assignment for our dial-up users without problem with the old Ripe-181 format. Now when we try to make a new registration we receive the following > message: > > > Acknowledgement message from database software > > Your e-mail: > > > From: "Infostrada Staff Internet" <staff(a)iunet.it > > <mailto:staff@iunet.it>> > > > Cc: > > > Subject: Aggiornamento > > > Date: Fri, 11 May 2001 16:29:24 +0200 > > > Msg-Id: <031d01c0da26$d913a690$19391197(a)infostrada.it > > <mailto:031d01c0da26$d913a690$19391197@infostrada.it>> > > > > has been processed by the automatic update procedure at the RIPE NCC. > > Diagnostic output follows: > > > > ------------------------------------------------------------------------ > > > > > > New FAILED: [inetnum] 151.39.51.0 - 151.39.51.255 > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > New FAILED: [inetnum] 151.39.0.0 - 151.39.255.255 > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > Update messages to <auto-dbm(a)ripe.net <mailto:auto-dbm@ripe.net>> are > > converted into > > RPSL format before processing. This will continue until > > May 14, 2001. Please see <http://www.ripe.net/rpsl> for > > more information. Can you tell me what I can do? Best regards

2 1

RIPE DB vs. IRRd
by Dmitry Safronov 16 May '01

16 May '01

Hello! Could you please describe the difference between RIPE DB and IRRd? Is there a necessity of moving to the RIPE DB version from IRRd? Thank you. -- Best regards, _____________________________________________________________________ Dmitry Safronov Rostelecom/Internet Centre Russia Tel: +007 (095) 334-9983 Fax: +007 (095) 339-2415

1 0

RIPE-181 to RPSL Migration; Completed switch-over to phase 2
by DB-News 14 May '01

14 May '01

Dear Colleagues, (Apologies for multiple messages). This is to announce that we have completed the phase 1 of migration. Starting from today, Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database has also been changed. In summary, from 14th May, 2001: =============================== RIPE Database: ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPSL format TEST Database: ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPSL format Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from http://www.ripe.net/rpsl/. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

RIPE-181 to RPSL Migration; Phase 2.
by DB-News 10 May '01

10 May '01

Dear Colleagues, (Apologies for multiple messages). On and from Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database will also be changed. In summary, from 14th May, 2001: =============================== RIPE Database: - ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RP S L format TEST Database: - ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RP S L format On Monday, 14th May, 2001, we cannot guarantee that an update message sent to <auto-dbm(a)ripe.net> will use a specific update path (RPSL or RIPE-181). Thus, we advise that updates in RIPE-181 format should be sent to <auto-181(a)ripe.net> and that updates in RPSL format should be sent to <auto-rpsl(a)ripe.net>. Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from http://www.ripe.net/rpsl/. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee - -------------- Database Group RIPE NCC

1 0

can NRTM handle divergent schemas?
by George Michaelson 10 May '01

10 May '01

Hi. Sorry for comparative silence from APNIC, we're back looking at getting the V3 code beyond test-compile state into pilot service. Andy Linton has been looking at this with me and we're now pretty sure the only schema element we don't have in APNIC 181 objects in-hand is the referred-by field. Having worked out its a nic-hdl, we figure that for 'old' data we just make this the existing meta-maintainer for APNIC and can do that easily in ripe2rpsl. But we have this problem about having country: fields in domain/inetnum/person objects. If we modify schema here, re-compile whoisd, are we able to run NRTM feeds to you and have your side strip non-conformant attributes, or is there some relax mode for NRTM where it doesn't care? My reading of code is a bit hazy here. I can't see where you are going to bypass schema checks in NRTM. If thats the case, we'd have to either overload remarks: fields to preserve this data (which is yucky) or you need to revise the RIPE schema. We should be able to take a feed incoming anyway (and would like to do that asap) but we're worried about how you can take a feed back from us if we do the codechange in the defs/* here. cheers -George -- George Michaelson | APNIC Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net

2 1