- db-wg - mailman.ripe.net

Delay in Mail Processing
by Shane Kerr 29 Jul '04

29 Jul '04

Dear Colleagues, Delivery of mail to the RIPE NCC was delayed from 17:00 CEST 28 July 2004 to 09:30 CEST 29 July 2004. Update e-mails sent to the RIPE Database were delayed. All e-mails were processed normally after this time. Web updates and synchronous updates were unaffected. We apologise for any inconvenience this may have caused. Sincerely, -- Shane Kerr Software Manager RIPE NCC

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training 21 Jul '04

21 Jul '04

Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Training Team RIPE NCC **************************************************************************** COURSE DATES AND VENUES ======================== Date: Friday 15 October 2004 Time: 0900 - 1700 Location: Geneva, Switzerland AND: Date: Tuesday 23 November 2004 Time: 0900 - 1700 Location: Damascus, Syria AND: Date: Friday 17 December 2004 Time: 0900 - 1700 Location: Amsterdam, the Netherlands ***************************************************************************** REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Early Registration Transfer (ERX) - Final Stage
by leo vegoda 19 Jul '04

19 Jul '04

Dear Colleagues, On 29 July 2004 the RIPE NCC will begin the final stage of the Early Registration Transfer [ERX] Project. This transfer will involve the former "Class C" space in 196.0.0.0/8 and 198.0.0.0/8. Networks in 196.0.0.0/8 that will eventually go to AfriNIC will not be included in this transfer. The schedule for the networks in 192/8 will be announced later. ERX: FINAL STAGE Because of the large number of registrations involved, approximately 3000 networks, a CGI has been introduced to allow the contacts to specify their preference for the networks, without direct involvement of Hostmasters. The transfer will take place in two phases. In the first phase, notifications will be sent out to the contacts (listed for the affected networks). After this notification, there will be a period of one month in which decisions can be made with regards to these networks. After one month, the transfer will be finalised and notifications of the changes made will be sent out. The RIPE NCC Hostmasters are available to help in case of questions or doubts. Please contact them at: <er-transfer(a)ripe.net>. FURTHER INFORMATION: The aim of the ERX project is to move IP address and AS Number registrations that were made before the advent of the RIR system to the appropriate RIR database. The ERX project is necessary because the database where these early registrations were recorded was inherited by ARIN, the RIR for North America, even though many networks using addresses assigned in this period were located in regions now served by other RIRs. ERX PROJECT: COMPLETED TRANSFERS The first stage of the project involved the movement of AS Number registrations. This began in August 2002. The second stage of the project involved the movement of IPv4 address registrations from the former "Class B" space (/16 networks in 128.0.0.0/8 - 191.0.0.0/8). This was started in December 2002 and finished in April 2004. More information about the ERX Project can be found on our web site at: http://www.ripe.net/db/erx/ Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

help
by Suchok Ardmard 29 Jun '04

29 Jun '04

Dear paticipant I have been first to installing a RPSL solfwarebut I got a experiented when update database as show below.Would consider and advise me.What was aproblem. As this case I have attach a more detial show below # dbupdate -c ../conf/rip.config -f test SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 0 Modify: 1 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Modify FAILED: [route] 202.47.249.0/24AS9931 ***Info: Syntax check passed route: 202.47.249.0/24 descr: CAT route object for THIX origin: AS9931 mnt-by: MAINT-THIX-CAT-TH changed: k(a)localhost.com 20040620 source: RADB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thank you Suchok A. This e-mail protected by CAT Internet Antivirus

1 0

Prototype of RPSLng Whois Server
by DB Role Account 28 Jun '04

28 Jun '04

[ Apologies for duplicate messages ] Dear Colleagues, The RIPE NCC Software Engineering Group provides an RPSLng prototype whois server on host rpslng.ripe.net, port 53001. RPSLng is an effort to extend the RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. The prototype RPSLng whois server has been updated to implement draft-blunk-rpslng-05.txt the latest Internet Draft of the RPSLng effort: ftp://ftp.ripe.net/internet-drafts/draft-blunk-rpslng-05.txt One discrepancy between the draft and the prototype server is that, the optional list of prefixes between the '{' and '}' in the "mnt-routes:" attributes of AUT-NUM and ROUTE6 objects has not been implemented. This functionality will be added later. The prototype database contains a snapshot of the RIPE Whois Database. It can be updated by sending mails to <rpslng-auto(a)ripe.net>. Please note, this database is only for test purposes and updates performed on it will NOT be reflected on the production RIPE Whois Database. The prototype RPSLng server was put into production in May 2003. We have refreshed the contents of the prototype database using a recent snapshot from the live RIPE Whois Database. We have kept the ROUTE6 objects, as well as AUT-NUM objects with "mp-*" attributes, while refreshing the contents. Up-to-date details can be found at: http://www.ripe.net/db/rpslng Regards, Shane Kerr Software Engineering Department Manager RIPE NCC

1 0

Delay in mailed updates to Database
by Shane Kerr 15 Jun '04

15 Jun '04

Colleagues, Due to shortage of free disk space on the main Whois server, mail updates were not processed between 14/06/2004 at 20:30 and 15/06/2004 at 14:00. The problem is now fixed, and updates are being processed normally. Updates that were submitted using Webupdates and Syncupdates were processed during this period without interruption. Apologies for the inconvenience. Best Regards, -- Shane Kerr Software Engineering Department Manager RIPE NCC

1 0

Proposed Change 2004.2: Removal of "referral-by:" Attribute
by Engin Gunduz 14 Jun '04

14 Jun '04

Dear Colleagues, This is a proposed change to improve the content of the RIPE Database. Please review and let us know if you have any comments. [2004.2] Removal of "referral-by:" Attribute from the MNTNER Object ------------------------------------------------------------------- Change: Remove the "referral-by:" attribute from the MNTNER objects' schema. This attribute is currently a mandatory attribute for MNTNER objects. The RIPE NCC will also remove this attribute from all existing MNTNER objects in the RIPE Whois Database. Motivation: The "referral-by:" attribute was introduced into MNTNER objects when the RIPE Whois Database was transitioning from version 2 whois software to version 3, which implements RFC2622 (RPSL) and RFC2725 (RPS Security). "referral-by:" is defined in RFC2725: ============== referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object. auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes. The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere. ============== The RIPE NCC introduced the "referral-by:" attribute as a place-holder, without implementing its functionality. It was thought that the attribute would be useful in the future and make it as compatible as possible with RFC2622 and RFC2725. However, it is now clear that an attribute that is not currently used (and with no plans to use it in the near future) is confusing for the database users. It can easily be re-introduced if the need arises. Regards, Engin Gunduz RIPE NCC Software Engineering Department References: [RFC2622] Routing Policy Specification Language (RPSL) ftp://ftp.ripe.net/rfc/rfc2622.txt [RFC2725] Routing Policy System Security ftp://ftp.ripe.net/rfc/rfc2725.txt

1 0

ANNOUNCEMENT: "auth:" Attribute is Now Searchable
by DB-News 14 Jun '04

14 Jun '04

Dear Colleagues, This is a short announcement to inform you that the "auth:" attribute of MNTNER and IRT objects are now inverse keys, allowing users to search for objects with a specific "auth:" attribute. The schemata of MNTNER and IRT objects are as follows: mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] An example query to find objects with the "auth: PGPKEY-00D69859", would be: $ whois -r -iauth PGPKEY-00D69859 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html mntner: ENGIN-MNT descr: Engin's mntner admin-c: EG792-RIPE upd-to: engin(a)ripe.net mnt-nfy: engin(a)ripe.net auth: PGPKEY-00D69859 mnt-by: ENGIN-MNT referral-by: RIPE-DBM-MNT changed: engin(a)ripe.net 20000313 changed: engin(a)ripe.net 20020531 source: RIPE Please note that inverse queries are only possible for PGPKEY and X509 authentication methods. The DES (CRYPT-PW) and MD5 (MD5-PW) encrypted passwords are not inverse searchable due to security concerns. If you have any questions, please do not hesitate to contact <ripe-dbm(a)ripe.net>. Regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

Modifying the ACL for the whois server
by Marwan El-Sherif 07 Jun '04

07 Jun '04

Dear Group, The whois server has a very good feature implemented in it that protects it from any form of abuse by enforcing ACL points. Now because most of our staff are not very familiar with the CLI whois client, we decided to go for a web interface for querying the whois server. So we ran into the problem of the web server's IP being blacklisted. I looked around the configuration of the ACL but could not find any way to exclude such IPs from the 'ACL points' system. We already have the proper protection from any abuse on the web server. We are running the RIPE Whois server 3.0.2. Is there any way to exclude certain IPs from being blacklisted? Regards, Marwan El-Sherif

2 1

problems with NRTM
by Patrick Rother 01 Jun '04

01 Jun '04

Hello. I have a problem with a NRTM running at ripe-dbase-3.2.0 software with mysql "Ver 12.22 Distrib 4.0.20, for pc-linux (i686)", i.e. there are some updates failing: # grep -i failed /opt/whoisd/log/ripupd/* | grep -v " 0 objects failed" | tail -20 ripupdlog_RIPE.20040524: 2 objects failed ripupdlog_RIPE.20040524:[4905870] 0.03s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4905925] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905934] 0.02s FAILED [as-set:][M:---] ripupdlog_RIPE.20040524:[4905945] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905959] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 4 objects failed ripupdlog_RIPE.20040524:[4906036] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906140] 0.45s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906209] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906272] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906309] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906377] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed # The database was completely rebuilt from the daily snapshot at ftp.ripe.net, but the problem still exists. I also tried ripe-dbase-3.2.0-org-obj-beta, but it segfaults regularly at or after every NRTM run, so it is not usable at all. What can I do to get this fixed? Thank you.

2 1