- db-wg - mailman.ripe.net

Draft Agenda V2
by Titley, Nigel 13 Sep '04

13 Sep '04

Folks, Following the discussion about abuse, Marco has agreed to give a short round up. This gives us version 2 of the Agenda Nigel +++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] F. IRT/Abuse roundup (MarcoH) [~15 min] Y. Input from other WGs Z. AOB -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Draft Minutes of the DB WG, version 2
by Titley, Nigel 13 Sep '04

13 Sep '04

Folks, This is the second draft of the minutes from the DB-WG RIPE 48. A very minor change has been made to item C. All actions are unchanged. Please check for your actions and try and report back. For reference I have open actions against RIPE NCC Wilfried Woeber Randy Bush + Niall O'Reilly Shane Kerr Nigel Titley Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Poetry object
by Titley, Nigel 13 Sep '04

13 Sep '04

In checking through the minutes and actions I note an action [AP48.3] on myself to clarify the issue of tech-c on the proposed poem: object. My proposal is that to be consistent we should have the tech-c attribute on both the Poem: and the Poetic-form: object. I also note Ulrich's suggestion that we should add the mnt-irt attribute to the Poem: object in order to provide a means of reporting abuse of (or by) the poem, and agree that this could be useful. Hopefully its inclusion at this early stage of the proceedings will allow tool-writers to make use of it rather than parsing lists of changed: attributes. I don't think we need the irt-mnt attribute on the Poetic-form object, but I'm willing to be persuaded. Please could I have comments on this, with the hope that we can tie off this action in Manchester, and get the new objects into the database. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [db-wg] draft agenda (V1) for DB-WG meeting, RIPE 49, Manches ter, UK
by Titley, Nigel 10 Sep '04

10 Sep '04

MarcoH wrote: > On Fri, Sep 10, 2004 at 04:44:39PM +0100, Titley, Nigel wrote: >> Sounds like a good idea. Do we have any volunteers to do a short >> presentation on where we got to? > > Happy to do it again, people who are not coming to manchester and do > want to give input, please mail me or the list. Great, how long a slot would you like? Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

domain: object normalization
by Pim van Pelt 06 Sep '04

06 Sep '04

Hi, I keep on bumping into something with the RIPE database. I'm used to the pedantic trailing dot in hostnames, such as 'www.bit.nl.'; I also always write domains like so: '122.109.193.in-addr.arpa.'. $ whois -h whois.ripe.net 122.109.193.in-addr.arpa. % 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 %ERROR:101: no entries found % % No entries found in the selected source(s). Without the trailing dot, this works just fine. Is it feasable to have the scanner normalize the hostname/domain into something that your backend can look up ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

9 11

call for agenda items, DB-WG, RIPE49 @ Manchester
by Wilfried Woeber, UniVie/ACOnet 31 Aug '04

31 Aug '04

Dear DB WG! The next DB-WG meeting is scheduled for week 39, 2004 in Manchester. Thus it is time again to ask for agenda items for the draft agenda. The "regular" items for the logistics will be provided by Nigel T. and myself, we will again have some contributions from the RIPE NCC, and whatever is contributed by your suggestions! Please note that the WG meeting will be managed by Nigel Titley as I am unable to come to Manchester this time - due to other events being scheduled for the very same week :-( Have a nice and successful meeting and get-together in Manchester! Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Virus Warning from the RIPE NCC
by Gerard Leurs 10 Aug '04

10 Aug '04

Dear Colleagues. We are sorry for duplicate emails. On Monday 9 August 2004, a virus (bagle) was mailed to several mailing lists operated by the RIPE NCC. Unfortunately, the virus passed through the filters of several of these lists. At the moment of writing we know this happened for the db-wg, eof-wg, routing-wg. And the wg-chairs. Please do not open any suspicious .zip files. Please make sure you delete any such mails. The RIPE NCC is working to resolve the issue. We apologise for any inconvenience this may have caused. Regards, Gerard Leurs, Operations department, RIPE NCC.

1 0

(no subject)
by Ripe-dbm 09 Aug '04

09 Aug '04

1 0

(no subject)
by Ripe-dbm 09 Aug '04

09 Aug '04

1 0

(no subject)
by Ripe-dbm 09 Aug '04

09 Aug '04

1 0

The release of RPSLng IRRToolSet
by Katie Petrusha 03 Aug '04

03 Aug '04

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.2 release of IRRToolSet. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. IRRToolSet implements the Internet Draft Document draft-blunk-rpslng-07 (ftp://ftp.ietf.org/internet-drafts/draft-blunk-rpslng-07.txt) The release contains peval, rpslcheck and RtConfig that support RPSLng. The software can be compiled using GCC-3.x, and also includes numerous contributed patches, bug fixes and changes related to the new draft. Please note that this will be the last release of IRRToolSet made by the RIPE NCC. Further IRRToolSet will be maintained by ISC (Internet Systems Consortium). More details regarding the migration will follow soon. The source code release and binary packages can be downloaded from: ftp://ftp.ripe.net/tools/IRRToolSet You can also check the IRRToolSet project page: http://www.ripe.net/db/irrtoolset Thanks to everyone who contributed the patches and bug fixes. Please contact <irrtoolset(a)ripe.net> for any comments. -- Best regards, Katie Petrusha RIPE NCC

1 0

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

Question on whois server software & org records
by william(at)elan.net 01 Jun '04

01 Jun '04

Quick question. Does current/latest/beta version of RIPE RPSL whois server now support org records? If not when in your plans will you be releasing server code that would support it? -- William Leibzon Elan Networks william(a)elan.net

2 1

Re: [db-wg] Country attribute to be removed?
by Wilfried Woeber, UniVie/ACOnet 28 May '04

28 May '04

Dear Hank, >Can we have a list of who was in attendance, ...while I think the "who" (explicit list of names) is less relevant, I guess you can get that piece of information from the nice folks at meeting(a)ripe.net ... >and how many people voted in favor of removing the country attribute usually we do not conduct formal votes, but rather try to find a common position regarding a particular proposal. The number of people in the room is (as usual) part of my WG summary report to the plenary which is available from the net at http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-plenary-db.p… >and whether people realized that the country attribute is used by organizations? Yes indeed, please see slide #4, item 1. and slide #5 action point AP 48.1 And in particular there was concern that the use of this entry is less than helpful for some parties because there is no way of making sure that data is "correct" (for any definition of correct [1] :-) and relevant for the particular use... >And what is the rule on consensus - does attendance at the RIPE conference >have more weight than discussion in the online mailing list? Yes, and no, but I presume this is off-topic in that context? >-Hank Wilfried. [1] one of the questions for which we could not find an answer is: which country to put into the object - . the country of residence of the LIR . the country of residence of the admin-c: of an piece of address space? . the country off "deployment" (which is fuzzy in itself...) ______________________________________________________________________

1 0

Country attribute to be removed?
by Hank Nussbacher 28 May '04

28 May '04

From the RIPE 48 minutes provided by Nick Hyrka: >DATABASE WORKING GROUP > >- It was agreed that the 'country:' attribute should be either removed or >be optional. I was not at the meeting but reading over the PDF: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-db-country.p… I believe the consensus in db-wg was to add a ZZ code and *not* to drop the country attribute totally. Israel uses the country attribute to filter ISP prefixes at its IIX: http://www.isoc.org.il/fr_reload.html?iix/2x_tech.4 When was it agreed to have it removed? -Hank

3 3

Re: [db-wg] Proposal: Abuse-C as a Reference
by Wilfried Woeber, UniVie/ACOnet 13 May '04

13 May '04

>Why do you not just use IRT? > >The prime reason, with which I agree, is that there is this 'mandatory' >encryption field. Two things: I have already polled the CERT community regarding the 'mandatory' for the key-cert attributes. As of today, I haven't heard anything which would prevent us from making those 'optional'. The NCC has confirmed that the modification would be straight-forward (and cheap :-). So this is solved, I think. Wilfried.

4 5