- db-wg - mailman.ripe.net

PGP auth?
by Gert Doering 23 Apr '01

23 Apr '01

Hi, with the old RIPE DB, PGP auth did only work with "inline" signatures (the "classic" PGP way), not with "MIME/multipart" signatures (the way "mutt" does them, and maybe other programs, and as this e-mail is signed). I remember that the new DB software was supposed to do MIME, and also MIME/multipart PGP, but it didn't work when I tried that ("request denied, forwarded to maintainer"). Could you please elaborate what the current state regarding MIME and/or PGP support is? thanks, Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

2 1

Re: New DB and line continuation?
by Andrei Robachevsky 23 Apr '01

23 Apr '01

Dear Berislav, Berislav Todorovic wrote: > > On Mon, 23 Apr 2001, DB-News wrote: > > >> The new version of the RIPE Database is now up and running! > >> All objects have been automatically converted to RPSL and loaded into > >> the new version of the Database. > > Congratulations! However, I have a question: > > When an attribute needs multiple lines to be described, the standard > RPSL format requires the attribute name to be mentioned once, while > successive lines are separted by spaces or commas (like you defined > in the transition document as well). It used to be like that in the > previous version of rpsl.ripe.net. However, right now, it seems to > me there is a strange RIPE-181/RPSL mix in place. See example: > Indeed, we tried to introduce as little changes to objects look as possible, while staying RPSL compliant. In fact, RPSL defines members attribute as: Attribute Value Type as-set <object-name> mandatory, single-valued, class key members list of <as-numbers> or optional, multi-valued <as-set-names> which means that one can have multiple 'members:' attribute, each of them may have a list of members separated by commas. So, formally there is no RPSL syntax violation. You can update your object to make it look like in RADB, both examples are accepted and valid in the RIPE database. Regards, Andrei > * RADB and old REIMP.RIPE (standard RPSL): > > [beri@nix00 ~]$ rwhois -h whois.ra.net as-kq > as-set: AS-KQ > descr: KPNQwest European routes > Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, > AS1234, AS1889, AS1891, AS1902, AS2043, > AS2049, AS2110, AS2135, AS2857, AS3220, > ... > > * RIPE (new format, RPSL): > > as-set: AS-KQ > descr: KPNQwest European routes > descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 > members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 > members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 > members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 > > While some of you might think this is not important, this is VERY > important to some of us who make scripts for automating our tasks with > the RIPE DB. > > Can anyone explain the reason of this RPSL syntax violation? Thanks! > > Regards, > 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 -- > --- _ _ ____ _ .--. ____ ____ __/_ --- > ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- -- Andrei Robachevsky DB Group Manager RIPE NCC

1 0

update problems with auto-dbm@ripe.net
by Frank Bohnsack 23 Apr '01

23 Apr '01

Dear colleagues, Our last aut-num update doen't accepted from auto-dbm(a)ripe.net ;-( It seems that there is a problems with password authentification and/or legacy RIPE-181 attributes. Please let me know whats wrong ... cheers Frank > -----Original Message----- > From: RIPE Database Management [mailto:ripe-dbm@ripe.net] > Sent: Monday, April 23, 2001 11:04 AM > To: mz(a)de.uu.net > Subject: Re: LONGACK AS1270 > > > > Acknowledgement message from database software > > > Your e-mail: > >> From: "Martin Ziegler" <mz(a)de.uu.net> >> Cc: >> Subject: LONGACK AS1270 >> Date: Mon, 23 Apr 2001 11:04:47 +0200 >> Msg-Id: <GMEGIAOLKNDLPJFCBJGLKEDDCCAA.mz(a)de.uu.net> > > has been processed by the automatic update procedure at the RIPE NCC. > Diagnostic output follows: > > ------------------------------------------------------------------------ > > > Update FAILED: Syntax error in object > password: ******** > ***Error: syntax error > ***Error: Unknown class encountered. > > Update FAILED: Syntax error in object > ***Error: syntax error > aut-num: AS1270 > as-name: UUNET-DE > descr: UUNET Germany > as-in: from AS517 100 accept AS-KQ > as-in: from AS553 100 accept AS-BELWUE > as-in: from AS680 100 accept AS-DFNTOWINISP > as-in: from AS1273 100 accept AS-ECRC > as-in: from AS1275 100 accept AS1275 > as-in: from AS1889 100 accept AS1889 > as-in: from AS2125 100 accept AS2125 > as-in: from AS2686 100 accept AS-IGNEMEA > as-in: from AS2871 100 accept AS-ISION > as-in: from AS3257 100 accept AS-NACAMAR AS5459 AS-NDH > as-in: from AS3320 100 accept AS-DTAG > as-in: from AS3569 100 accept AS3569 > as-in: from AS3573 100 accept AS3573 > as-in: from AS5378 100 accept AS-INSNET > as-in: from AS5401 100 accept AS-POP > as-in: from AS5427 100 accept AS-CONTRIBNET > as-in: from AS5430 100 accept AS-MOBILCOM > as-in: from AS5496 100 accept AS-WIREHUB > as-in: from AS5521 100 accept AS-CITYLINE > as-in: from AS5539 100 accept AS-SPACENET > as-in: from AS5549 100 accept AS-TELENOR > as-in: from AS5605 100 accept AS5605 > as-in: from AS5621 100 accept AS-CPSEUROPE > as-in: from AS5627 100 accept AS5627 > as-in: from AS6705 100 accept AS-PROFI > as-in: from AS6735 100 accept AS-SDTDECIX AS-SDTMAEF > as-in: from AS6754 100 accept AS-VIA > as-in: from AS8072 100 accept AS8072 > as-in: from AS8196 100 accept AS-NETSCALIBURDE > as-in: from AS8208 100 accept AS-CAMELOT > as-in: from AS8220 100 accept AS-COLT > as-in: from AS8298 100 accept AS-IDNET > as-in: from AS8319 100 accept AS-IXREGIO > as-in: from AS8351 100 accept AS8351 > as-in: from AS8354 100 accept AS8354 > as-in: from AS8360 100 accept AS8360 > as-in: from AS8373 100 accept AS8373 > as-in: from AS8379 100 accept AS-CYBERNETEU > as-in: from AS8397 100 accept AS-ZETNET > as-in: from AS8422 100 accept AS-NETCOLOGNE > as-in: from AS8442 100 accept AS8442 > as-in: from AS8469 100 accept AS-PIRONETNDH > as-in: from AS8477 100 accept AS-TESIONGLOBAL AS-SWCMGLOBAL > as-in: from AS8602 100 accept AS8602 > as-in: from AS8650 100 accept AS-TLI > as-in: from AS8735 100 accept AS8735 > as-in: from AS8767 100 accept AS-MNETDE > as-in: from AS8794 100 accept AS8794 > as-in: from AS8827 100 accept AS8827 > as-in: from AS8852 100 accept AS-GINKO > as-in: from AS8864 100 accept AS8864 > as-in: from AS8879 100 accept AS8879 > as-in: from AS8925 100 accept AS-TEUTOCLIENTS > as-in: from AS8939 100 accept AS-ADTECH > as-in: from AS8950 100 accept AS8950 > as-in: from AS8957 100 accept AS8957 > as-in: from AS9007 100 accept AS9007 > as-in: from AS9059 100 accept AS9059 > as-in: from AS9066 100 accept AS-BCC > as-in: from AS9067 100 accept AS9067 > as-in: from AS9072 100 accept AS-NEFKOM > as-in: from AS9099 100 accept AS9099 > as-in: from AS9164 100 accept AS9164 > as-in: from AS9175 100 accept AS9175 > as-in: from AS9188 100 accept AS9188 AS9067 > as-in: from AS11660 100 accept AS11660 > as-in: from AS12288 100 accept AS12288 > as-in: from AS12291 100 accept AS12291 > as-in: from AS12292 100 accept AS-TRANSKOM > as-in: from AS12313 100 accept AS-VERSATELDE AS-VERSATELCUSTDE > as-in: from AS12331 100 accept AS12331 > as-in: from AS12343 100 accept AS12343 > as-in: from AS12355 100 accept AS12355 > as-in: from AS12371 100 accept AS12371 > as-in: from AS12379 100 accept AS12379 > as-in: from AS12437 100 accept AS12437 > as-in: from AS12466 100 accept AS12466 > as-in: from AS12470 100 accept AS12470 AS-TLKNET AS15909 > as-in: from AS12531 100 accept AS12531 > as-in: from AS12532 100 accept AS-DIZ > as-in: from AS12555 100 accept AS12555 > as-in: from AS12574 100 accept AS12574 > as-in: from AS12581 100 accept AS-TOPSNET > as-in: from AS12595 100 accept AS12595 > as-in: from AS12598 100 accept AS12598 > as-in: from AS12610 100 accept AS12610 > as-in: from AS12612 100 accept AS12612 > as-in: from AS12625 100 accept AS12625 > as-in: from AS12638 100 accept AS12638 > as-in: from AS12643 100 accept AS12643 > as-in: from AS12647 100 accept AS12647 > as-in: from AS12664 100 accept AS12664 > as-in: from AS12678 100 accept AS12678 > as-in: from AS12722 100 accept AS12722 > as-in: from AS12796 100 accept AS12796 > as-in: from AS12813 100 accept AS-WORNET > as-in: from AS12853 100 accept AS12853 > as-in: from AS12857 100 accept AS12857 > as-in: from AS12886 100 accept AS-LEWTELNET > as-in: from AS12888 100 accept AS12888 > as-in: from AS12892 100 accept AS12892 > as-in: from AS12899 100 accept AS12899 > as-in: from AS12915 100 accept AS12915 > as-in: from AS12916 100 accept AS12916 > as-in: from AS12919 100 accept AS12919 > as-in: from AS12930 100 accept AS12930 > as-in: from AS13003 100 accept AS13003 > as-in: from AS13006 100 accept AS13006 > as-in: from AS13012 100 accept AS13012 AS15456 > as-in: from AS13039 100 accept RS-NEW > as-in: from AS13040 100 accept AS13040 > as-in: from AS13043 100 accept AS13043 > as-in: from AS13045 100 accept AS13045 AS15790 > as-in: from AS13083 100 accept AS13083 > as-in: from AS13090 100 accept AS13090 AS15492 > as-in: from AS13101 100 accept AS-TNG > as-in: from AS13129 100 accept AS-GAT > as-in: from AS13152 100 accept AS13152 > as-in: from AS13157 100 accept AS13157 > as-in: from AS13237 100 accept AS13237 > as-in: from AS13247 100 accept AS13247 > as-in: from AS13270 100 accept AS13270 > as-in: from AS15374 100 accept AS15374 > as-in: from AS15392 100 accept AS15392 > as-in: from AS15438 100 accept AS15438 > as-in: from AS15465 100 accept AS15465 > as-in: from AS15486 100 accept AS15486 > as-in: from AS15563 100 accept AS15563 > as-in: from AS15579 100 accept AS15579 > as-in: from AS15622 100 accept AS15622 > as-in: from AS15698 100 accept AS15698 > as-in: from AS15709 100 accept AS15709 > as-in: from AS15763 100 accept AS15763 > as-in: from AS15781 100 accept AS15781 > as-in: from AS15813 100 accept AS15813 > as-in: from AS15889 100 accept AS15889 > as-in: from AS15894 100 accept AS15894 > as-in: from AS15904 100 accept AS15904 AND AS9115 > as-in: from AS15933 100 accept AS15933 > as-in: from AS15968 100 accept AS15968 > as-in: from AS15987 100 accept AS15987 > as-in: from AS16038 100 accept AS-COMCITY > as-in: from AS16103 100 accept AS-NETZTECHOUT > as-in: from AS16126 100 accept AS16126 > as-in: from AS16148 100 accept AS16148 > as-in: from AS16152 100 accept AS16152 > as-in: from AS16233 100 accept AS16233 > as-in: from AS16356 100 accept AS16356 > as-out: to AS517 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS553 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS680 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1273 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1275 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1889 announce ANY > as-out: to AS2125 announce ANY > as-out: to AS2686 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS2871 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3257 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3320 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3569 announce ANY > as-out: to AS3573 announce ANY > as-out: to AS5378 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5401 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5427 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5430 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5496 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5521 announce ANY > as-out: to AS5539 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5549 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5605 announce ANY > as-out: to AS5621 announce ANY > as-out: to AS5627 announce ANY > as-out: to AS6705 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS6735 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS6754 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8072 announce ANY > as-out: to AS8196 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8208 announce ANY > as-out: to AS8220 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8298 announce ANY > as-out: to AS8319 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8351 announce ANY > as-out: to AS8354 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8360 announce ANY > as-out: to AS8373 announce ANY > as-out: to AS8379 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8397 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8422 announce ANY > as-out: to AS8442 announce ANY > as-out: to AS8469 announce ANY > as-out: to AS8477 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8602 announce ANY > as-out: to AS8650 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8735 announce ANY > as-out: to AS8767 announce ANY > as-out: to AS8794 announce ANY > as-out: to AS8827 announce ANY > as-out: to AS8852 announce ANY > as-out: to AS8864 announce ANY > as-out: to AS8879 announce ANY > as-out: to AS8925 announce ANY > as-out: to AS8939 announce ANY > as-out: to AS8950 announce ANY > as-out: to AS8957 announce ANY > as-out: to AS9007 announce ANY > as-out: to AS9059 announce ANY > as-out: to AS9066 announce ANY > as-out: to AS9067 announce ANY > as-out: to AS9072 announce ANY > as-out: to AS9099 announce ANY > as-out: to AS9164 announce ANY > as-out: to AS9175 announce ANY > as-out: to AS9188 announce ANY > as-out: to AS11660 announce ANY > as-out: to AS12288 announce ANY > as-out: to AS12291 announce ANY > as-out: to AS12292 announce ANY > as-out: to AS12313 announce ANY > as-out: to AS12331 announce ANY > as-out: to AS12343 announce ANY > as-out: to AS12355 announce ANY > as-out: to AS12371 announce ANY > as-out: to AS12379 announce ANY > as-out: to AS12437 announce ANY > as-out: to AS12466 announce ANY > as-out: to AS12470 announce ANY > as-out: to AS12531 announce ANY > as-out: to AS12532 announce ANY > as-out: to AS12555 announce ANY > as-out: to AS12574 announce ANY > as-out: to AS12581 announce ANY > as-out: to AS12595 announce ANY > as-out: to AS12598 announce ANY > as-out: to AS12610 announce ANY > as-out: to AS12612 announce ANY > as-out: to AS12625 announce ANY > as-out: to AS12638 announce ANY > as-out: to AS12643 announce ANY > as-out: to AS12647 announce ANY > as-out: to AS12664 announce ANY > as-out: to AS12678 announce ANY > as-out: to AS12722 announce ANY > as-out: to AS12796 announce ANY > as-out: to AS12813 announce ANY > as-out: to AS12853 announce ANY > as-out: to AS12857 announce ANY > as-out: to AS12886 announce ANY > as-out: to AS12888 announce ANY > as-out: to AS12892 announce ANY > as-out: to AS12899 announce ANY > as-out: to AS12915 announce ANY > as-out: to AS12916 announce ANY > as-out: to AS12919 announce ANY > as-out: to AS12930 announce ANY > as-out: to AS13003 announce ANY > as-out: to AS13006 announce ANY > as-out: to AS13012 announce ANY > as-out: to AS13039 announce ANY > as-out: to AS13040 announce ANY > as-out: to AS13043 announce ANY > as-out: to AS13045 announce ANY > as-out: to AS13083 announce ANY > as-out: to AS13090 announce ANY > as-out: to AS13101 announce ANY > as-out: to AS13129 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS13152 announce ANY > as-out: to AS13157 announce ANY > as-out: to AS13237 announce ANY > as-out: to AS13247 announce ANY > as-out: to AS13270 announce ANY > as-out: to AS15374 announce ANY > as-out: to AS15392 announce ANY > as-out: to AS15438 announce ANY > as-out: to AS15465 announce ANY > as-out: to AS15486 announce ANY > as-out: to AS15563 announce ANY > as-out: to AS15579 announce ANY > as-out: to AS15622 announce ANY > as-out: to AS15698 announce ANY > as-out: to AS15709 announce ANY > as-out: to AS15763 announce ANY > as-out: to AS15781 announce ANY > as-out: to AS15813 announce ANY > as-out: to AS15889 announce ANY > as-out: to AS15894 announce ANY > as-out: to AS15904 announce ANY > as-out: to AS15933 announce ANY > as-out: to AS15968 announce ANY > as-out: to AS15987 announce ANY > as-out: to AS16038 announce ANY > as-out: to AS16103 announce ANY > as-out: to AS16126 announce ANY > as-out: to AS16148 announce ANY > as-out: to AS16152 announce ANY > as-out: to AS16233 announce ANY > as-out: to AS16356 announce ANY > remarks: Community definitions > remarks: > remarks: Communities for incoming customer routes > remarks: > remarks: Community Definition > remarks: ============================================== > remarks: 1270:80 Set LocalPref within AS1270 to 80 > remarks: 1270:120 Set LocalPref within AS1270 to 120 > remarks: > admin-c: OD3-RIPE > tech-c: AT51 > notify: neteng(a)de.uu.net > remarks: Peering requests should be send to peering(a)de.uu.net > mnt-by: AS1270-MNT > changed: mz(a)de.uu.net 20010423 > source: RIPE > ***Error: syntax error > ***Error: Unknown class encountered. > > RIPE Database Maintenance Department (Automatic Section) > -- Frank Bohnsack email fb(a)de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net

2 1

auto-rpsl@ripe.net MIME parser problem and auth failure
by Daniel Roesen 23 Apr '01

23 Apr '01

Hi, the auto-rpsl(a)ripe.net robot MIME parser doesn't understand quoted-printable encoding. I think it should. Second, all our updates are failing with "authorisation failed". Our objects are protected by a maintainer object with PGP-Auth. I guess there is a problem with signature verification Best regards, Daniel Roesen -- Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9

1 0

Re: New DB and line continuation?
by RIPE Database Administration 23 Apr '01

23 Apr '01

Hi, Berislav Todorovic, Thank you for reporting this. We are investigating. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC Berislav Todorovic <beri(a)kpnqwest.net> writes: * On Mon, 23 Apr 2001, DB-News wrote: * * >> The new version of the RIPE Database is now up and running! * >> All objects have been automatically converted to RPSL and loaded into * >> the new version of the Database. * * Congratulations! However, I have a question: * * When an attribute needs multiple lines to be described, the standard * RPSL format requires the attribute name to be mentioned once, while * successive lines are separted by spaces or commas (like you defined * in the transition document as well). It used to be like that in the * previous version of rpsl.ripe.net. However, right now, it seems to * me there is a strange RIPE-181/RPSL mix in place. See example: * * * RADB and old REIMP.RIPE (standard RPSL): * * [beri@nix00 ~]$ rwhois -h whois.ra.net as-kq * as-set: AS-KQ * descr: KPNQwest European routes * Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, * AS1234, AS1889, AS1891, AS1902, AS2043, * AS2049, AS2110, AS2135, AS2857, AS3220, * ... * * * RIPE (new format, RPSL): * * as-set: AS-KQ * descr: KPNQwest European routes * descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 * members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 * members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 * members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 * * While some of you might think this is not important, this is VERY * important to some of us who make scripts for automating our tasks with * the RIPE DB. * * Can anyone explain the reason of this RPSL syntax violation? Thanks! * * Regards, * 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 -- * --- _ _ ____ _ .--. ____ ____ __/_ --- * ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ * ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- * *

1 0

New RPSL Query of aut-num objects
by Sascha E. Pollok 23 Apr '01

23 Apr '01

Dear Folks, apologies if this has been discussed before or is considered not being relevant to most of you but if I do a query like below, the main difference (beside the new RPSL-look-and-feel of course) is that the as-block: object is shown AND that there is one space missing as a separator between field-descriptors and the content of the field compared to all other objects. Again, this might be irrelevant to most of you that do /(\S+)\s+(.*)/ or whatever but I just wanted to ask. Regards, Sascha ----------- % whois AS12731 as-block: AS12288 - AS13311 descr: RIPE NCC ASN block remarks: These AS numbers are further assigned by RIPE NCC remarks: to LIRs and end-users in the RIPE NCC region remarks: Please refer to RIPE Document ripe-185 remarks: and RIPE Document ripe-147 admin-c: NN32-RIPE tech-c: OPS4-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster(a)ripe.net 20010423 source: RIPE aut-num: AS12731 as-name: IPHH descr: IPHH Internet Port Hamburg GmbH descr: Global AS Routing-Policy import: from AS3300 action pref=100; accept ANY AND NOT {0.0.0.0/0}

1 0

Fwd: BLOCK: RIPE
by Christian Panigl, ACOnet/VIX/UniVie 23 Apr '01

23 Apr '01

Hmmm, reasonable diligence or epidemic paranoia ? Just got this one forwarded, thought it might be worth letting you know ... Cheers CP ================================ X-Mailer: Forte Agent 1.8/32.548 Message-ID: <6uu6ets5102thcbdrigof2l7urtmd2gmjl(a)4ax.com> Date: Sun, 22 Apr 2001 20:48:13 -0400 From: Daniel Norton <danorton(a)SUESPAMMERS.ORG> To: SPAM-L(a)PEACH.EASE.LSOFT.COM Reply-To: Daniel Norton <danorton(a)SUESPAMMERS.ORG> Sender: Spam Prevention Discussion List <SPAM-L(a)PEACH.EASE.LSOFT.COM> Organization: . Subject: BLOCK: RIPE RIPE's database is down for an indeterminate period of time. Since it might be impossible to determine an abuse contact address without the RIPE database, you might wish to consider blocking all RIPE traffic until they get things back in order. Here are the RIPE IP address ranges: 24.132/14 62/8 139.20/14 139.24/14 139.28/15 141.0/10 141.64/12 141.80/14 141.84/15 145.224/12 145.240/13 145.248/14 145.252/15 145.254/16 149.202/15 149.204/16 149.206/15 149.208/12 149.224/12 149.240/13 149.248/14 150.254/16 151.13/16 151.14/15 151.16/12 151.32/11 151.64/12 151.80/15 151.3/16 151.4/15 151.82/16 151.91/16 151.92/15 151.95/16 160.216/14 160.220/16 160.44/14 160.48/12 163.156/14 163.160/12 164.0/11 164.32/13 164.40/16 164.128/12 171.16/12 171.32/15 192.106.196/23 192.162/16 192.164/14 192.71/16 193/8 194/8 195/8 198.17.117/24 212/8 213/8 217/8 -- Daniel Norton ----- End of forwarded message from Daniel Norton -----

3 2

Migration of the TEST database is completed
by Andrei Robachevsky 23 Apr '01

23 Apr '01

Dear Colleagues, The TEST database has been successfully migrated to v3 software. All objects in the TEST database were converted to RPSL compliant format. You can continue using the TEST database till 14 May as follows: - <test-dbm(a)ripe.net> mail robot accepts updates in RIPE-181 format with some limitations. - <test-rpsl(a)ripe.net> mail robot accepts updates in RPSL format. After that day changes in robots' functionality will follow the plan fro the production database. Please see http://www/ripencc/pub-services/db/rpsl/announcement.html and http://www/ripencc/pub-services/db/rpsl/index.html for more information. Finding objects in the TEST Database: Do whois -h test-whois.ripe.net <Search String> e.g. whois -h test-whois.ripe.net PB3-TEST The whois options that work in the RIPE Database also work in the TEST Database. We invite you to try them. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 3

First phase of the migration to the new RIPE Database is completed
by DB-News 23 Apr '01

23 Apr '01

Dear Colleagues, The new version of the RIPE Database is now up and running! All objects have been automatically converted to RPSL and loaded into the new version of the Database. The first phase of the migration has been successfully completed. The following mail robots accept updates to the RIPE Database: <auto-dbm(a)ripe.net> - updates are accepted in RIPE-181 format and automatically translated into RPSL. However, several restrictions apply to such updates: empty and misspelled attributes are not allowed, PGP auth is not supported. Also, RPSL authorization rules apply. <auto-rpsl(a)ripe.net> - updates are accepted in RPSL format. This setup will be in place till 14 May, 2001. For more information about the migration please visit http://www.ripe.net/ripencc/pub-services/db/rpsl/announcement.html and http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html Best Regards, Andrei Robachevsky DB Group RIPE NCC

1 0

Migration of the TEST database is delayed
by Andrei Robachevsky 18 Apr '01

18 Apr '01

Dear colleagues, Unfortunately due to hardware problems with the computer running TEST database server we need to delay the migration of the TEST database that was planned on 17-18.04. We plan to start the migration of the TEST database tomorrow, 19.04. We will keep you informed. Sorry for any inconvenience this caused. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RIPE Database Software Version 3.0.
by DB-News 05 Apr '01

05 Apr '01

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0 of the RIPE Database software. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). You can download this release by anonymous ftp from the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0.tar.gz We remind you that you can also test the functionality of this release of the new RIPE Whois server in 2 ways: - by querying the host rpsl.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database; this mirror is in RPSL format; - by using the RIP Test Database; you can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test this release in both ways, and send us your comments. Comments and bug reports may be sent to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your message. This is a moderated mailing list so some delays in subscription are possible. Version 3 of the RIPE Database software will be deployed on the RIPE Whois server on 23 April 2001. Please see http://www.ripe.net/rpsl/ for more information on how this will affect you. There is a mailing list to discuss the migration to the new service, <reimp-mig-tf(a)ripe.net>. To subscribe, send a message to <majordomo(a)ripe.net> with the line: subscribe reimp-mig-tf in the body of your message. As for the db-beta mailing list, this is a moderated mailing list so some delays and so some delays in subscription are possible. If you have any other questions or comments, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC

1 0

RE: Another issue related to the migration
by Lu, Ping 03 Apr '01

03 Apr '01

Andrei, The existing ripe2rpsl tool will automatically translate "AS-" to "ASN-" for the aut-num object and I think "ASN-" is more meaningful than "AS_". Best Regards. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: Thursday, March 29, 2001 11:10 AM > To: db-wg(a)ripe.net; routing-wg(a)ripe.net; Migration TF; lir-wg(a)ripe.net > Subject: Another issue related to the migration > > > Dear Colleagues, > > [Apologies for duplicate messages] > > One issue related to RIPE-181 to RPSL migration escaped our > attention and has > not been discussed. It is related to reserved prefixes that > cannot appear in > object names according to RPSL specification (RFC2622) which says: > > "Names starting with certain prefixes are reserved for > certain object types. > Names starting with "as-" are reserved for as set names. > Names starting with > "rs-" are reserved for route set names. Names starting with > "rtrs-" are > reserved for router set names. Names starting with "fltr-" > are reserved for > filter set names. Names starting with "prng-" are reserved > for peering set > names." > > Unfortunately "as-name:" attribute is an object name in RPSL > and we have 133 > aut-num objects with as-name starting with reserved 'AS-' prefix. > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC >

2 1

Re: Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Hi Rob, Rob Evans wrote: > > Hi Andrei, > > > Please find below a list of milestones related to the migration to the new > > version of the RIPE Database. > > Silly question; are the times UTC or CET? Sorry about this, all times are CEST (Central European Summer Time, UTC+2). > > Thanks, > Rob Regards, Andrei

1 0

Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Dear Colleagues, [apologies for duplicate messages] Please find below a list of milestones related to the migration to the new version of the RIPE Database. Your comments and suggestions are welcome. Should you have any further question regarding the migration, please don't hesitate to contact me. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ------------------------------------------------------------------ Date Actions ------------------------------------------------------------------ 4.04 Final release of the v3.0 DB software 12.04 Advised mirror's switchover to rpsl.ripe.net. - Reminder is sent to NRTM clients on 9.04 - Starting from this date NRTM clients that mirror the RIPE Database are advised to use the new server at rpsl.ripe.net, port 4444 for mirroring. 17-18.04 Migration of the TEST database to v3.0 (RPSL) - TEST Database becomes a RPSL database. Updates are accepted in RPSL format at <test-dbm(a)ripe.net>. - No RIPE-181 TEST database exists anymore. - Estimated downtime 6 hours. 22.04-23.04 Migration of the RIPE Database to v3.0 (RPSL) - New server becomes the official RIPE Database server at 00:00 23.04. - Updates received after 16:00, 22.04 are queued until the new server becomes operational. After that they are automatically converted to RPSL and processed by the new server. New syntax and authorization rules apply. - Downtime in queries will be deliberately introduced to mark the migration. Whois server downtime is planned from 18:00, 22.04 till 00:00 23.04. During this time a message explaining the migration process will be sent as a whois query reply. 23.04, 00:00 New server becomes the official RIPE Database server - Short (1-2 min) downtime is possible during final tests. 23.04, 02:00 New server starts processing updates - Two mail robots are available: <auto-dbm(a)ripe.net> - updates in RIPE-181 format (restrictions apply) <auto-rpsl(a)ripe.net> - updates in RPSL format (recommended).

1 0

RIPE Database Software V3.0 compliance test.
by DB-News 30 Mar '01

30 Mar '01

Dear Colleagues, If you have software that works with RIPE Database Software, then you should make sure that it works with Version 3.0, which will be put into production next month. Compliance tests are available at: http://www.ripe.net/ripencc/pub-services/db/rpsl/usercl.html More information about Version 3.0 of the RIPE Database Software and how it will affect you is available at: 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

RE: Another issue related to the migration
by Hallgren, Michael 29 Mar '01

29 Mar '01

Hi, > > > Dear Colleagues, [...] > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. Yes. Agree. Been hinting customers to trash/modify such names prior to migration date - not knowing whether or not such conflict would be treated auto-magically... Regards Michael > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > -- Michael Hallgren, Eng., Teleglobe, MH2198-RIPE

1 0

Another issue related to the migration
by Andrei Robachevsky 29 Mar '01

29 Mar '01

Dear Colleagues, [Apologies for duplicate messages] One issue related to RIPE-181 to RPSL migration escaped our attention and has not been discussed. It is related to reserved prefixes that cannot appear in object names according to RPSL specification (RFC2622) which says: "Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names." Unfortunately "as-name:" attribute is an object name in RPSL and we have 133 aut-num objects with as-name starting with reserved 'AS-' prefix. Our suggestion how to deal with these objects is: 1. Send a message to the maintainers of these objects asking them to change the name to avoid conflict with RPSL specification. 2. Give two-week notice period after which ripe-dbm will convert non compliant as-names using the following mapping: AS-ASNAME -> AS_ASNAME. This is more a "cosmetic" change as as-name is not even a lookup key in the RIPE Database. Your comments and suggestions are appreciated. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: Summary of the Migration issues
by Lu, Ping 21 Mar '01

21 Mar '01

Some questions followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net [snip] > ---------------------------------------- > 1. Route object creation (RFC2725 implications) > > In order to create route object in the RIPE DB, one needs to have > corresponding objects (inetnum or less specific route, and > aut-num) and > pass proper authorization from these objects. > > The problem occurs when someone needs to register route > object which has > either prefix, or origin, or the both from non RIPE IP/ASN space. > > Proposed solution: > 1.1 An as-block object(s) encompassing the non RIPE ASN space will be > created with "mnt-lower:" protected by mntner with NONE auth. > > 1.2 An encompassing inetnum object with "mnt-routes:" protected by > mntner with NONE auth will be created. This will eliminate need for > corresponding inetnum creation and will reduce amount of redundant > information. > > 1.3 In case origin of a route object being created is from non RIPE > space, users will need to create corresponding aut-num object in the > RIPE DB. > Does 1.3 means RIPE is going accept non-RIPE aut-num(AN) object thus a mntner(MT) object to protect that AN thus some person(PN) objects associated with that MT ? And is RIPE going to allow the NONE auth specified in 1.1 and 1.2 to be changed to a real MT once the rightful holder created them ? > > 2. Updates in RIPE-181 format > How about the ftp mirror ? Will RIPE-181 format text files still be available to download after April 23, 2001 or just the RPSL format text files ? [big cut for the rest]

2 1

Summary of the Migration issues
by Andrei Robachevsky 20 Mar '01

20 Mar '01

Dear Colleagues, Please let me summarize the migration issues that have been discussed already and highlight some issues that require more attention. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ---------------------------------------- 1. Route object creation (RFC2725 implications) In order to create route object in the RIPE DB, one needs to have corresponding objects (inetnum or less specific route, and aut-num) and pass proper authorization from these objects. The problem occurs when someone needs to register route object which has either prefix, or origin, or the both from non RIPE IP/ASN space. Proposed solution: 1.1 An as-block object(s) encompassing the non RIPE ASN space will be created with "mnt-lower:" protected by mntner with NONE auth. 1.2 An encompassing inetnum object with "mnt-routes:" protected by mntner with NONE auth will be created. This will eliminate need for corresponding inetnum creation and will reduce amount of redundant information. 1.3 In case origin of a route object being created is from non RIPE space, users will need to create corresponding aut-num object in the RIPE DB. 2. Updates in RIPE-181 format Migration plan allows users to send updates in RIPE-181 format for some time (until May 14th to <auto-dbm(a)ripe.net>, from May 14th till October 15th to <auto-181(a)ripe.net>) after the migration. In such case objects are automatically converted to RPSL. However the switchover to the new version of the RIPE Database occurs on 23 of April, and since then the following constraints will apply: 2.1 PGP authentication PGP authorization scheme will not work with <auto-dbm(a)ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl(a)ripe.net>. The problem occurs because after ripe181->RPSL transformation it is impossible to verify signature. For this reason, some updates requiring PGP auth may be rejected during migration. It advisable not to send such updates from 22 April, 9a.m. till 23 April 9a.m. 2.2 New syntax rules When processing an object after ripe181->RPSL conversion new v3.0 syntax rules apply. The results of this will be: - empty attributes (i.e. having no value) are not allowed; - some attributes that were optional before are now mandatory; Also some undocumented behaviour of the v2.x Database will not be supported, namely: - attribute aliases (please see list of aliases attached) are not allowed; - inetnum object cannot be specified in prefix notation. 2.3 New authorization rules New authorization rules defined by RFC2725 apply to creation of aut-num and route objects. See 1. 3. Objects with names containing reserved RPSL prefixes They will be renamed on 2 of April. All references will be updated accordingly. Currently there are 6 of them in the RIPE Database. mntner: AS-5532MNTB mntner: AS-NETLINK-MNT mntner: AS-THENET-MNT mntner: AS-NEW1-MNT mntner: RS-MNT mntner: AS-MNT 4. Broken PGP certificates. They will be deleted on 2 of April. ---------------------- v2.x attribute aliases (not supported in v3.0!): Alias Attrbute change -> changed email -> e-mail fax -> fax-no remark -> remarks deleted -> delete asname -> as-name rev-svr -> rev-srv network -> inetnum netnum -> inetnum

3 3

RFC2725
by Holger Muenx 15 Mar '01

15 Mar '01

Guten Tag, I hope this is the correct forum - if not please direct me to a more appropriate one. After following the discussion for a while I am still unsure about the exact consequences of the activation of RFC2725 on 23-Apr-2001. I will try to summarize my understanding: Please check this and correct me where necessary. You will find a list of open questions at the bottom of this mail. As Frank Bohnsack wrote in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00090.html AS numbers are allocated to regional registries as shown in http://www.isi.edu/in-notes/iana/assignments/as-numbers and the IPv4 address space allocated to various registries as shown in http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space RFC2725 states in section 9.9 that during addition of an inetnum the most specific matching inetnum is being searched to find the required authentication. During addition of a route the aut-num of the originating AS and either a most specific matching inetnum or a most specific matching route is being searched to find the required authentication. This leaves UUNET in a curious situation. For example, UUNET uses AS 702 which is in the range 1 - 1876 allocated by the ARIN and the inetnum 193.96.0.0/13 which is in 193.0.0.0/8 allocated by the RIPE. With RFC2725 in place UUNET would have its aut-num record in a different registry than its inetnum, rendering it impossible to add routes for the 193.0.0.0/8. There are probably more complications caused by moving data from one registry to another. For example, some people will continue to expect information at the original registry because they did not prepare for RFC2725, breaking mechanisms such as automatic prefix filter creation. Andrei Robachevsky presented two suggestions in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00095.html Suggestion 1 means that RIPE will implement changes so that RFC2725 will be in effect for AS numbers and IP address space allocated by RIPE only. No checks according to RFC2725 will be done for all other AS numbers and IP address space. Suggestion 2 means that there will be encompassing inetnum objects which contain the address ranges assigned to other registries than RIPE. These objects will have a maintainer with NONE authentication so that everybody can add routes within these inetnum which refer to their own aut-num records. No decision has been made on whether one of the suggestion and, if so, which of them will be implemented. So far my understanding. Please review - if it is completely wrong I hope that I at least amused you. ;-) Thank you for your help! Holger Münx EMEA Access & Backbone Networks UUNET Deutschland GmbH Tel. +49 231 972 0 Sebrathweg 20 Fax. +49 231 972 1111 44149 Dortmund, Germany Holger.Muenx(a)de.uu.net http://www.de.uu.net/

1 0

RE: RIPE DB transition and RFC2725
by Lu, Ping 09 Mar '01

09 Mar '01

Comments followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > Sent: Friday, March 09, 2001 11:24 AM > To: Lu, Ping > Cc: 'Frank.Bohnsack(a)de.uu.net'; db-wg(a)ripe.net > Subject: RE: RIPE DB transition and RFC2725 > > > > Lu, Ping (plu(a)cw.net) on March 9: > > Finally somebody express the same concerns as ours. > > > > I have a discussion with the RIPE staff at the RIPE-38 > meeting about this. > > > > There are two seperate issues here: > > 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) > should allow > > foreign references ( using objects from other RR database) or not. > > RFC does not prohibit foreign references. As a matter of fact, RIPE > has a workaround that does this. > > Please also see the companion RFC RFC 2769 for making RFC 2725 checks > across registries. RFC 2769 and 2725 together yield a global > distributed registry. Of course, it requires cooperation form other > (at lease regional) registries. > The wrokaround means DISABLE integrity checking. That's an option for RIPE-DB v2.x (RIPE-181) but we haven't tried RIPE-DB v3.x yet. Also the workaround raises another question: How do you authorize the route creation from a foreign AS ? That's exactly the issue from Andrei's previous email (subject: Migration issues: route creation). And the solution to this needs to be discussed further. ( Hi, Andrei, any more suggestions from the community yet ?) > > 2. The assumption of RIPE-DB v3.0 is that all object > references have to be > > resloved locally( ie. with source: RIPE). > > > > The 2nd issue means if any ISP with ARIN's AS number want > to register a > > route with RIPE you have to register your PN(person) then > your MT(mntner) > > then your AN(aut-num) with RIPE first. > > > > So each ISP has to maintain a different set of objects with each RR. > > AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE > > AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN > > AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC > > AS123(in JP) -> MNT-AS123-JP -> NIC456-JP > > AS123(in DE) -> MNT-AS123-DE -> NIC456-DE > > .... > > > > Just to remember to update all these information everytime > there is a little > > tiny change. > > It is fun, isn't it ? > > > > And NO you can't get all route information from just one RR > unless we all > > sit down and seriously > > talking about the GLOBAL issues. > > > > Ping Lu > > Cable & Wireless Global > > Network Tools and Analysis Group, USA > > W: +1-703-292-2359 > > E: plu(a)cw.net > > > > > > > -----Original Message----- > > > From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] > > > Sent: Friday, March 09, 2001 7:43 AM > > > To: db-wg(a)ripe.net > > > Subject: RIPE DB transition and RFC2725 > > > > > > > > > Dear colleagues, > > > > > > Yes, I know the deadline for transition comments is over, but > > > after studying RFC2725 we need a confirmation for our > understanding. > > > > > > RFC2725 defined the need for an "as-block" object for each related > > > "aut-num" object and an "inetnum" object for each related > > > "route" object. > > > > > > The assignment of AS blocks and IP space is managed by IANA. > > > * http://www.isi.edu/in-notes/iana/assignments/as-numbers > > > * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space > > > > > > Does the new RIPE DB manage only "as-blocks" and > "inetnums" which are > > > assigned to RIPE ? > > > > > > 1/ And if I'm right, is it true that we can't store our ASes > > > 702, 1270 > > > and a lot of routes (assigned to ARIN) in the new > RIPE database ? > > > > > > 2/ And is it true that we therefore can't set our route > > > (assigned to RIPE) > > > objects origin to our ASes ? > > > > > > The solution for 1/ is moving to ARIN, but what might be the > > > solution for 2/ > > > ? > > > > > > You say a big ISP is anyway talking to multiple IRRs, but I > > > think customers > > > who want to peer with these can't get complete information > > > while using RIPE > > > DB only. > > > > > > > > > Cheers > > > Frank > > > > > > -- > > > Frank Bohnsack email fb(a)de.uu.net > > > UUNET, A Worldcom Company phone +49 (0)231 972-1495 > > > EMEA Access & Backbone Networks fax +49 (0)231 972-1188 > > > Team Dortmund web www.de.uu.net > > > > > > Cengiz > > -- > Cengiz Alaettinoglu Packet Design >

2 1

RE: RIPE DB transition and RFC2725
by Lu, Ping 09 Mar '01

09 Mar '01

Finally somebody express the same concerns as ours. I have a discussion with the RIPE staff at the RIPE-38 meeting about this. There are two seperate issues here: 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) should allow foreign references ( using objects from other RR database) or not. 2. The assumption of RIPE-DB v3.0 is that all object references have to be resloved locally( ie. with source: RIPE). The 2nd issue means if any ISP with ARIN's AS number want to register a route with RIPE you have to register your PN(person) then your MT(mntner) then your AN(aut-num) with RIPE first. So each ISP has to maintain a different set of objects with each RR. AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC AS123(in JP) -> MNT-AS123-JP -> NIC456-JP AS123(in DE) -> MNT-AS123-DE -> NIC456-DE .... Just to remember to update all these information everytime there is a little tiny change. It is fun, isn't it ? And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] > Sent: Friday, March 09, 2001 7:43 AM > To: db-wg(a)ripe.net > Subject: RIPE DB transition and RFC2725 > > > Dear colleagues, > > Yes, I know the deadline for transition comments is over, but > after studying RFC2725 we need a confirmation for our understanding. > > RFC2725 defined the need for an "as-block" object for each related > "aut-num" object and an "inetnum" object for each related > "route" object. > > The assignment of AS blocks and IP space is managed by IANA. > * http://www.isi.edu/in-notes/iana/assignments/as-numbers > * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space > > Does the new RIPE DB manage only "as-blocks" and "inetnums" which are > assigned to RIPE ? > > 1/ And if I'm right, is it true that we can't store our ASes > 702, 1270 > and a lot of routes (assigned to ARIN) in the new RIPE database ? > > 2/ And is it true that we therefore can't set our route > (assigned to RIPE) > objects origin to our ASes ? > > The solution for 1/ is moving to ARIN, but what might be the > solution for 2/ > ? > > You say a big ISP is anyway talking to multiple IRRs, but I > think customers > who want to peer with these can't get complete information > while using RIPE > DB only. > > > Cheers > Frank > > -- > Frank Bohnsack email fb(a)de.uu.net > UUNET, A Worldcom Company phone +49 (0)231 972-1495 > EMEA Access & Backbone Networks fax +49 (0)231 972-1188 > Team Dortmund web www.de.uu.net >

3 2

RIPE DB transition and RFC2725
by Frank Bohnsack 09 Mar '01

09 Mar '01

Dear colleagues, Yes, I know the deadline for transition comments is over, but after studying RFC2725 we need a confirmation for our understanding. RFC2725 defined the need for an "as-block" object for each related "aut-num" object and an "inetnum" object for each related "route" object. The assignment of AS blocks and IP space is managed by IANA. * http://www.isi.edu/in-notes/iana/assignments/as-numbers * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space Does the new RIPE DB manage only "as-blocks" and "inetnums" which are assigned to RIPE ? 1/ And if I'm right, is it true that we can't store our ASes 702, 1270 and a lot of routes (assigned to ARIN) in the new RIPE database ? 2/ And is it true that we therefore can't set our route (assigned to RIPE) objects origin to our ASes ? The solution for 1/ is moving to ARIN, but what might be the solution for 2/ ? You say a big ISP is anyway talking to multiple IRRs, but I think customers who want to peer with these can't get complete information while using RIPE DB only. Cheers Frank -- Frank Bohnsack email fb(a)de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net

1 0

Re: Announcement: Hardware upgrade of whois server
by Stephen Burley 07 Mar '01

07 Mar '01

Sorry for any duplication > Dear colleagues, > > After experiencing performance slow-down on our whois service, we > decided > to upgrade the hardware of our primary whois server. > > The upgrade will take place on 9 March, 2001, Friday. It will start at > 8:00am CET and planned to last approximately 2 hours. Just a quick quaestion, Why Friday and why during working hours? All our maint slots have to be out of hours and not preceding a weekend. Curious -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------

2 1

Announcement: Hardware upgrade of whois server
by RIPE Database Administration 07 Mar '01

07 Mar '01

Dear colleagues, After experiencing performance slow-down on our whois service, we decided to upgrade the hardware of our primary whois server. The upgrade will take place on 9 March, 2001, Friday. It will start at 8:00am CET and planned to last approximately 2 hours. During the operation, whois queries will be directed to our secondary server and the incoming update messages will be queued, to be processed later. We apologize for any inconvenience this may cause. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

2 1