From ripe-dbm at ripe.net Thu Mar 1 14:24:35 2001 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Thu, 01 Mar 2001 14:24:35 +0100 Subject: Release of patch for ripe-dbase-3.0beta2 software. Message-ID: <200103011324.OAA26064@office.ripe.net> Dear Colleagues, [Apologies for multiple mails]. This mail is to notify you that today, we have released a patch for the ripe-dbase-3.0beta2 software. This patch has several bug fixes. Specifically, this patch includes, amongst other fixes: - TEMPORARY tables in MySQL 3.23 are supported; - a major memory leak on Solaris 8 has been fixed; - CLIENTADDRESS referral now properly passes addresses; - the "-m" queries work now; - memory allocation bug in dbupdate is fixed; - multiple notification problems have been fixed; - improved acknowledgement and notification message formats. You can download this patch from the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta3.patch.gz We remind you that you can also test the functionality of this patch for the RIP whois server in 2 ways: - By querying the host reimp.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 , and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the patch in both ways, and let us know your opinions. Please send your comments and bug reports to the mailing list. To subscribe to this list, send a message to with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. If you are interested in providing to the community tools and documentation supporting the RIPE-181 to RPSL migration, you are welcome to join the reimp-mig-tf mailing list. To subscribe to this list, follow the instructions given above for subscribing to the db-beta list (doing s/db\-beta/reimp\-mig\-tf/, of course :-). If you have any questions, please contact . Regards, A. M. R. Magee ______________ Database Group RIPE NCC From ripe-dbm at ripe.net Thu Mar 1 14:34:31 2001 From: ripe-dbm at ripe.net (RIPE NCC Staff) Date: Thu, 01 Mar 2001 14:34:31 +0100 Subject: Release of patch for ripe-dbase-3.0beta2 software. Message-ID: <200103011334.OAA27381@office.ripe.net> Dear Colleagues, [Apologies for multiple, identical messages]. This mail is to notify you that today, we have released a patch for the ripe-dbase-3.0beta2 software. This patch has several bug fixes. Specifically, this patch includes, amongst other fixes: - TEMPORARY tables in MySQL 3.23 are supported; - a major memory leak on Solaris 8 has been fixed; - CLIENTADDRESS referral now properly passes addresses; - the "-m" queries work now; - memory allocation bug in dbupdate is fixed; - multiple notification problems have been fixed; - improved acknowledgement and notification message formats. You can download this patch at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta3.patch.gz We remind you that you can also test the functionality of this patch for the RIP whois server in 2 ways: - By querying the host reimp.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 , and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the patch in both ways, and let us know your opinions. Please send your comments and bug reports to the mailing list. To subscribe to this list, send a message to 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. If you are interested in providing to the community tools and documentation supporting the RIPE-181 to RPSL migration, you are welcome to join the reimp-mig-tf mailing list. To subscribe to this list, follow the instructions given above for subscribing to the db-beta list (doing s/db\-beta/reimp\-mig\-tf/, of course :-). If you have any questions, please contact . Regards, A. M. R. Magee ______________ Databse Group RIPE NCC From andrei at ripe.net Mon Mar 19 16:37:17 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 19 Mar 2001 16:37:17 +0100 Subject: Summary of the Migration issues Message-ID: <3AB627AD.CD56AD8C@ripe.net> 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 , from May 14th till October 15th to ) 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 robot after 23 April. Updates requiring PGP auth should be sent directly to . 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 From Frank.Bohnsack at de.uu.net Mon Mar 19 17:07:42 2001 From: Frank.Bohnsack at de.uu.net (Frank Bohnsack) Date: Mon, 19 Mar 2001 17:07:42 +0100 (MET) Subject: Summary of the Migration issues In-Reply-To: <3AB627AD.CD56AD8C@ripe.net> Message-ID: Dear Colleagues, On 19-Mar-2001 Andrei Robachevsky wrote: > 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. * Means that, all non RIPE IP/ASN space is available on 23 of April as default or should we send an request if needed ? * Should we still use the human mail interface for "aut-num" and "mntner" creations on 23 of April ? * Can we assume that the database on 23 of April is the same like the current RPSL mirror ? many thanks Frank -- Frank Bohnsack email fb at 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 From andrei at ripe.net Mon Mar 19 16:37:17 2001 From: andrei at ripe.net (andrei at ripe.net) Date: Mon, 19 Mar 2001 16:37:17 +0100 Subject: Summary of the Migration issues In-Reply-To: <3AB627AD.CD56AD8C@ripe.net> References: <3AB627AD.CD56AD8C@ripe.net> Message-ID: 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 , from May 14th till October 15th to ) 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 robot after 23 April. Updates requiring PGP auth should be sent directly to . 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 From andrei at ripe.net Tue Mar 20 10:44:12 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 20 Mar 2001 10:44:12 +0100 Subject: Summary of the Migration issues References: Message-ID: <3AB7266C.2D8CC807@ripe.net> Dear Colleagues, [Apologies for duplicate messages] Please let me answer some of your questions. Frank Bohnsack asked: >> 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. > > * Means that, all non RIPE IP/ASN space is available on 23 of April as default > or should we send an request if needed ? > Non RIPE IP space will be protected by the encompassing inetnum object. There is no need to create a corresponding inetnum object in case of "foreign" route creation. In case 1.3 people will be able to create a corresponding aut-num object themselves. > * Should we still use the human mail interface for "aut-num" and "mntner" > creations on 23 of April ? > Yes. Except for aut-num creations in non RIP ASN space (case 1.3), when the request should be sent to or . > * Can we assume that the database on 23 of April is the same like the current > RPSL mirror ? > RPSL mirror is being kept in sync with the production RIPE Database. That means the contents of the both databases is the same. This will slightly change at the beginning of April when we plan to begin final pre production phase. Several objects (like as-block, encompassing inetnum) will be added to RPSL database. In a few days we are going to present a detailed migration plan, and your comments are highly appreciated. Ernesto Baschny asked: > > PGP authorization scheme will not work with robot > > after 23 April. Updates requiring PGP auth should be sent directly to > > . > > Does that refer only to route/inetnum objects, or to all (also > person-objects)? If so, can person-objects already be created > using the adress auto-rpsl at ripe.net the same way we used the > auto-dbm at ripe.net (with PGP)? This restriction applies to all updates/objects sent in RIPE-181 format to . So if you are using PGP authorization, starting from 23 of April you should send your updates to in RPSL format. To avoid confusion will not be valid until April 23. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC From andrei at ripe.net Tue Mar 20 10:53:11 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 20 Mar 2001 10:53:11 +0100 Subject: Summary of the Migration issues Message-ID: <3AB72887.56CDF27F@ripe.net> Dear Colleagues, [Apologies for duplicate messages. We suspect that this message was not delivered to yesterday, 19 March] 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 , from May 14th till October 15th to ) 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 robot after 23 April. Updates requiring PGP auth should be sent directly to . 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 From plu at cw.net Tue Mar 20 18:10:14 2001 From: plu at cw.net (Lu, Ping) Date: Tue, 20 Mar 2001 12:10:14 -0500 Subject: Summary of the Migration issues Message-ID: Some questions followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu at 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] From andrei at ripe.net Wed Mar 21 11:11:21 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 21 Mar 2001 11:11:21 +0100 Subject: Summary of the Migration issues References: Message-ID: <3AB87E49.10A08D25@ripe.net> "Lu, Ping" wrote: > > Some questions followed. > > Ping Lu > Cable & Wireless Global > Network Tools and Analysis Group, USA > W: +1-703-292-2359 > E: plu at 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 ? > Yes. Current version of the Database requires aut-num object to be present in order to be referenced in 'origin:' attribute. So for routes with foreign origins people should have created aut-num, mntner, person, etc. No change in fact. > 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 ? > If the rightful holder wishes to maintain the space. Though I think we may want to look for more scalable solutions. > > > > 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 ? > After April 23, 2001 only RPSL text files will be available. It is impossible to present all objects and attributes in RIPE-181 format. > [big cut for the rest] Regards, Andrei Robachevsky DB Group Manager RIPE NCC From andrei at ripe.net Thu Mar 29 18:09:41 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 29 Mar 2001 18:09:41 +0200 Subject: Another issue related to the migration Message-ID: <3AC35E45.2A2659CA@ripe.net> 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 From michael.hallgren at teleglobe.com Thu Mar 29 18:25:00 2001 From: michael.hallgren at teleglobe.com (Hallgren, Michael) Date: Thu, 29 Mar 2001 17:25:00 +0100 Subject: Another issue related to the migration Message-ID: 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 From plu at cw.net Thu Mar 29 19:37:34 2001 From: plu at cw.net (Lu, Ping) Date: Thu, 29 Mar 2001 12:37:34 -0500 Subject: Another issue related to the migration Message-ID: 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 at cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei at ripe.net] > Sent: Thursday, March 29, 2001 11:10 AM > To: db-wg at ripe.net; routing-wg at ripe.net; Migration TF; lir-wg at 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 > From db-news at ripe.net Fri Mar 30 12:39:57 2001 From: db-news at ripe.net (DB-News) Date: Fri, 30 Mar 2001 12:39:57 +0200 Subject: RIPE Database Software V3.0 compliance test. Message-ID: <200103301039.MAA29575@office.ripe.net> 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 . Regards, A. M. R. Magee -------------- Database Group RIPE NCC