- db-wg - mailman.ripe.net

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

RPSL question
by Frank Bohnsack 18 Jan '01

18 Jan '01

Dear Colleague, I'm writting a Perl RPSL parser module and have a understanding problem with part 2 "RPSL Names, Reserved Words, and Representation" page 5 of RFC 2622 ;-( "A value of an attribute may also be a list of one of these types. A list is represented by separating the list members by commas ",". For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note that being list valued and being multiple valued are orthogonal. A multiple valued attribute has more than one value, each of which may or may not be a list. On the other hand a single valued attribute may have a list value." Ok, a multiple attribute value can be a single value or a 'comma list' of values. But the last sentence confused me - "a single valued attribute may have a list value" ? Means that "aut-num: AS123, AS456, ..." is a correct attribute of an aut-num object ?!?! Cheers Frank

3 2

RE: Loop in AS macro
by Lu, Ping 18 Jan '01

18 Jan '01

Hi, Shane, Thank for the tip. It works. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Thursday, January 11, 2001 4:46 AM > To: Lu, Ping > Cc: 'cengiz(a)packetdesign.com'; Wilfried Woeber, UniVie/ACOnet; > farrache(a)cc.in2p3.fr; db-wg(a)ripe.net; routing-wg(a)ripe.net; > Henk.Uijterwaal(a)ripe.net > Subject: RE: Loop in AS macro > > > Ping, > > What I usually do (in Perl) is something like this: > > my %entries_seen; > foreach my $as_set (@as_sets) { > # if we've seen this value (recursive as-set), skip > next if ($entries_seen{$as_set}); > > # note that we've seen this as-set > $entries_seen{$as_set}++; > > # get a list of members of the as-set, and process appropriately > foreach my $member (members($as_set)) { > # add member as-sets to the list of as-sets to process > push(@as_sets, $member) if ($member =~ /^AS-/i); > > # other processing here > . > . > . > } > } > > If you're using some other scripting language, it will be > different, but > typically no more difficult. If you're in C, you may want to > use glib or > something like that, otherwise you'll need to use a list or > hash you write > yourself. > > Shane Kerr <shane(a)ripe.net> > Database Software Engineer > RIPE NCC > +31 20 535 4427 > > On Wed, 10 Jan 2001, Lu, Ping wrote: > > > Hi, I am new to this list and would like to ask a (maybe > stupid) question to > > the dicussion: > > > > If we want to write a script to expand the AS MACRO, how > can we avoid to go > > into a loop if multiple AS-MACROs reference each other ? > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: 703-292-2359 > > E: plu(a)cw.net > > > > > -----Original Message----- > > > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > > > Sent: Wednesday, January 10, 2001 12:14 PM > > > To: Shane Kerr > > > Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; > > > db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net > > > Subject: RE: Loop in AS macro > > > > > > > > > > > > Shane Kerr (shane(a)ripe.net) on January 10: > > > > Gilles, Wilfried, and all, > > > > > > > > This is not a bug, or even an inconsistency. Consider > the following > > > > as-macro objects: > > > > > > > > as-macro: AS-X > > > > members: AS-Y, AS123 > > > > > > > > as-macro: AS-Y > > > > members: AS-X, AS456, AS789 > > > > > > > > In this case, AS-X and AS-Y both expand to the same > aut-num objects: > > > > AS123, AS456, and AS789. However, they may have different > > > maintainers, > > > > contacts, descriptions, and so on. In RPSL, many more > > > kinds of loops are > > > > possible as well, in as-set, route-set, and filter-set objects. > > > > > > RPSL defines semantics when loops exist. However, it does > not promote > > > them, or prohibit additional restrictions by the registry > operators > > > not to have loops. > > > > > > > > > > > External software that deals with the set objects needs > to do loop > > > > detection in order to prevent infinite loops. For as-set > > > objects (which > > > > are as-macro objects in RIPE-181), this is fairly easy: > > > keep a list or > > > > hash of the AS sets expanded, and don't expand them again. > > > For route-set > > > > and filter-set objects it is not quite so easy. If you > > > need help with > > > > these, you can send me and e-mail and I can explain the > > > techniques that > > > > I've used for these objects. > > > > > > > > Shane Kerr <shane(a)ripe.net> > > > > Database Software Engineer > > > > RIPE NCC > > > > +31 20 535 4427 > > > > > > > > p.s. This is actually a feature, not an bug. :) > > > > > > > > p.p.s. It has been argued (by me) that RPSL allows > objects that are > > > > logically impossible, but the RFC authors don't seem to > think so! > > > > > > > > On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > > > > > Hi Gilles, > > > > > > > > > > I guess we wouldn't be able to check against those > > > accidents at the time > > > > > of a DB _update_... > > > > > > > > > > But checking the RR internal _data_ consistency could > > > maybe become part > > > > > of the RIS (or similar) project? > > > > > > > > > > Henk, any comments? > > > > > > > > > > An interesting aside: I guess similar problems > could occur with > > > > > RPSL-based RRs? > > > > > > > > > > -WW > > > > > > > > _________________________________:____________________________ > > > _________ > > > > > 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 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > ~~~~~~~~~ > > > > > > > > > > To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, > > > admin-c(a)tli.de > > > > > CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net > > > > > Subject: Loop in AS macro > > > > > Date: Wed, 10 Jan 2001 10:28:15 +0100 > > > > > From: Gilles Farrache <farrache(a)cc.in2p3.fr> > > > > > > > > > > Dear database managers, > > > > > > > > > > I notice a loop in the followings AS-MACRO, in fact > > > AS-TELEDANMARKINTERNATIONAL > > > > > is calling AS-TLI which is calling AS-TELEDK which is > > > calling AS-TELEDANMARKINTERNATIONAL. > > > > > (and all that make that our automatic filter generation > > > tool fails) > > > > > > > > > > Could you correct those macro and will the Ripe database > > > management provide any > > > > > control on that kind of loop ? > > > > > > > > > > Gilles > > > > > > > > > > as-macro: AS-TELEDANMARKINTERNATIONAL > > > > > descr: Tele Danmark customers outside Denmark > > > > > as-list: AS1902 AS12461 > > > > > as-list: AS8881 AS-KOMTEL > > > > > as-list: AS13194 AS-BITE > > > > > as-list: AS6709 > > > > > as-list: AS8650 AS-TLI > > > > > as-list: AS8542 > > > > > as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 > > > AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 > > > > > as-list: AS12546 > > > > > as-list: AS15389 > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 20001103 > > > > > changed: toba(a)tdk.dk 20001117 > > > > > changed: tee(a)tdk.dk 20001123 > > > > > changed: jesper(a)skriver.dk 20001228 > > > > > changed: jesper(a)skriver.dk 20010109 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TLI > > > > > descr: Talkline GmbH, Internet Division > > > > > descr: List of ASes according to Talkline > Internet (AS8650) > > > > > descr: and customers > > > > > as-list: AS5605 > > > > > as-list: AS6783 > > > > > as-list: AS8650 > > > > > as-list: AS8881 > > > > > as-list: AS12461 > > > > > as-list: AS12546 > > > > > as-list: AS-TELEDK > > > > > as-list: AS-GLOBAL > > > > > tech-c: TLIP1-RIPE > > > > > admin-c: TLIP1-RIPE > > > > > notify: peering(a)tli.de > > > > > mnt-by: TALKLINE-MNT > > > > > changed: thomas(a)tli.de 19990923 > > > > > changed: thomas(a)tli.de 19991020 > > > > > changed: thomas(a)tli.de 19991025 > > > > > changed: thomas(a)tli.de 20001023 > > > > > changed: thomas(a)tli.de 20001025 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TELEDK > > > > > descr: Tele Danmark and Tele Danmark customers > > > > > as-list: AS-TELEDANMARKDANISH > > > > > as-list: AS-TELEDANMARKINTERNATIONAL > > > > > as-list: AS-BELBONEMEMBERS > > > > > as-list: AS-GLOBAL > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 19990922 > > > > > changed: jesper(a)skriver.dk 19991019 > > > > > changed: jesper(a)skriver.dk 19991025 > > > > > changed: jesper(a)skriver.dk 19991210 > > > > > changed: toba(a)tdk.dk 20000903 > > > > > source: RIPE > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > > > > > > > > > > > > > > > > Cengiz > > > > > > -- > > > Cengiz Alaettinoglu Packet Design Inc. > > > > > > > > >

1 0

Re: CERT Object summary (for review in Paris)
by Wilfried Woeber, UniVie/ACOnet 17 Jan '01

17 Jan '01

Below please find the most recent summary of our proposal for a "CERT Object", taking into account all the comments I am aware of - as well as a couple of proposals for clarifiaction and open issues. This is for discussion and review by CERTs/IRTs in Barcelona and input for the DB-WG meeting next week in Amsterdam. Attributes that are "DB-Standard" get no tag, the CERT Object specific attributes are tagged with "*". For the description of the "DB-Standard" attributes refer to the DB Software documentation, please. * irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [ ] auth: [mandatory] [multiple] [ ] * mnt-cert: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] * signature: [mandatory] [multiple] [] * encryption: [mandatory] [single] [] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] - The irt: attribute assigns a unique name to an IRT object. Q: [to the NCC DB group] in your example, the IRT: attribute's value looks like a handle, and it is used like a handle in references. Wouldn't it be "cleaner" to allow person: and role: like identifications and assign a handle, which is then used to as a reference? Q: Another issue: assuming that a similar facility becomes available in other registry databases, should we try to "reserve" a handle-suffix for those handles? The use of "RIPE-CERT" got me wondering... - The mnt-cert: attribute points to a key-cert: object; it is checked when this irt object is added to e.g. an inetnum:. For all objects that support a pointer to an irt: object, a new attribute is defined as a reference pointing to an irt: object. This attribute might be named irt-c: or incident-c: Q: from an end-user point of view, wouldn't it be more "obvious" to use abuse-c: ? Q: We said that as a value for the auth: attribute, only PGPKEY-<key-id> would be allowed. Do we really need both, the (restricted) auth: _and_ the mnt-cert: ? - The signature: attribute points to a key-cert: object which defines one or more keys that are user by the CERT's team members to sign and/or encrypt messages sent by the team. - The encryption: attribute points to a key-cert: object which defines the key that should be used to sign and/or encrypt messages sent to the team. Q: should we try to find a more "obvious" name for those tags? I could think of sig-from: and encrypt-to: (similar to SMTP mail from and rcpt to :-) or even from-irt: and to-irt: Wilfried.

2 1