- db-wg - mailman.ripe.net

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

Glimpse search on email strings
by Hank Nussbacher 13 May '04

13 May '04

How does one search for a specific email string via Glimpse: http://www.ripe.net/db/whois-free.html Or is this disabled? If so, suppose an email contact has to be changed globally and I want to find all objects where it is listed - how do I find it? Thanks, Hank

2 1

make auth inverse key
by kieber＠gatel.net 13 May '04

13 May '04

Re Shane, WG, just a quick reminder and followup to my short talk with Shane during RIPE48 regarding the closed action item on adding a reverse lookup feature for key-cert objects. You might want to have a look at agenda item ``I: Key Certificates to person role'', http://www.ripe.net/ripe/wg/db/minutes/ripe-44.html. My original idea was to change irt: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [ ] ... and mntner: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [ ] ... to irt: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [inverse key] ... and mntner: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [inverse key] ... and block inverse queries for CRYPT-PW and MD5-PW, allowing PGPKEY (and other possible future strong encrytion schemes) to be inversely queried. Than I could find all references to my key-cert object, and update those references in case I wish to delete a key-cert object (e.g. in case the key has been compromised). As far as I see, this has not yet been implemented, but is, according to Shane, a rather easy to add feature. -- Ulf Kieber email: kieber(a)gatel.net Sr. Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net

2 1

Abuse-C/IRT
by Ulrich Kiermayr 12 May '04

12 May '04

Hi *, Here are the Statistics from today I mentioned on Abuse-C/IRT IPV4 Statistics 2004-05-06 +----------+----------------------------+-------------------+----------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+----------------------------+-------------------+----------+ | inetnum | 3.8e+08 (100.0%) [/3.5 ] | 1048450 (100.0%) | 0 | +----------+----------------------------+-------------------+----------+ | irt | 2.6e+07 ( 6.9%) [/7.4 ] | 2244 ( 0.2%) | 20 | +----------+----------------------------+-------------------+----------+ | abuse | 7.1e+07 ( 18.6%) [/5.9 ] | 150727 ( 14.4%) | 0 | | abuse@ | 6.1e+07 ( 16.1%) [/6.1 ] | 113360 ( 10.8%) | 1050 | +----------+----------------------------+-------------------+----------+ IPV6 Statistics 2004-05-06 +----------+----------------------------+-------------------+----------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+----------------------------+-------------------+----------+ | inetnum | 2.9e+31 (100.0%) [/23.5 ] | 5360 (100.0%) | 0 | +----------+----------------------------+-------------------+----------+ | irt | 4e+29 ( 1.4%) [/29.7 ] | 135 ( 2.5%) | 12 | +----------+----------------------------+-------------------+----------+ | abuse | 4.4e+29 ( 1.5%) [/29.5 ] | 3213 ( 59.9%) | 0 | | abuse@ | 4.4e+29 ( 1.5%) [/29.5 ] | 3054 ( 57.0%) | 91 | +----------+----------------------------+-------------------+----------+ lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140

9 21

RE: [db-wg] Proposal: Abuse-C as a Reference
by Rodney Tillotson 11 May '04

11 May '04

Ulrich Kiermayr wrote at 5/6/04 09:25: > This abuse-c inherits all the features of irt as well ... Except that crypto is optional. Fair enough. > ... resulting in just one object for this area I suggest we keep IRT for the purpose for which it was built, and make no changes to it (so it will be different from the role or person used we make available for abuse). This might actually encourage the use of IRT objects, since it reduces the risk that CSIRTs will get abuse reports they mostly don't want. And IRTs may then be useful, so I don't support removing them. > Implementing abuse-c that way would give a 1:1 mapping between > irt and role and therefore making irt obsolete (and the existing > objects auto-convertable). I think the 1-1 mapping is unnecessary; auto-copying is still possible. Can you confirm that the abuse-c: attribute can also refer to an IRT object for people who want to do it that way? > Add the missing features from irt: to the person and role objects: > > person: [mandatory] [single] [lookup key] > address: [mandatory] [multiple] [ ] > phone: [mandatory] [multiple] [ ] > fax-no: [optional] [multiple] [ ] > e-mail: [optional] [multiple] [lookup key] > signature: [optional] [multiple] [ ] <-- > encryption: [optional] [multiple] [ ] <-- > nic-hdl: [mandatory] [single] [primary/look-up key] > remarks: [optional] [multiple] [ ] > notify: [optional] [multiple] [inverse key] > mnt-by: [optional] [multiple] [inverse key] > ref-nfy: [optional] [multiple] [inverse key] <-- > mnt-ref: [optional] [multiple] [ ] <-- > changed: [mandatory] [multiple] [ ] > source: [mandatory] [single] [ ] Do we need a dedicated attribute in role and person? abuse-mail: [optional] [multiple] [ ] (or the name could be 'abuse-mailbox' as in Ulrich's example) Does the attribute need to be a lookup key like e-mail? (again as in the example) Should we make the abuse-mail attribute mandatory for the object types concerned? But that might force us to use a new object type :-( > Query behaviour: > > Return abuse-c by default as well The thing to return is not the name of the abuse-c reference; it's the abuse-mail attribute of the object referred to. Perhaps that's what you meant anyway? > Return abuse-c by default as well > (or include default -c i.e. return abuse-c from the least specific > inetnum containing the ip in question). Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else; so somehow we have to walk the database for them and not put the burden on them or their client software. I do not believe we can expect tool writers (eg SpamCop, geektools) to do that for us; I do not believe we can deploy a different whois client. We might get away with publishing a different server location (whois-for-the-masses.ripe.net? abuse.ripe.net?); or with putting this behaviour on whois.ripe.net and moving the present behaviour to a new address. But don't we want to present the mail address derived from the _most_ specific inetnum (rather than the least)? > Change the -c flag to use abuse-c instead of mnt-irt. No need to change that behaviour if we take the above approach. Rodney Tillotson, JANET-CERT

6 10

Draft minutes for the RIPE 48 DB working group
by Titley, Nigel 08 May '04

08 May '04

Gentlefolk, Herewith first draft of the minutes for the WG meeting at RIPE 48 Comments and corrections to me please. 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

2 1

Re: [db-wg] Abuse-C/IRT
by Wilfried Woeber, UniVie/ACOnet 07 May '04

07 May '04

Hi Pim, >| Hmm, this is nice, but not really necessary, because with the -c flag in >| the whois-query you should get tho the allocated /40 anyway. >| >| i.e. your change should increase the # of objects, bur not the Footprint >| of the IRT > [ ... ] > , should I revert that software >change and NOT set mnt-irt in the more specifics, or should I leave it >as is. Opinions ? setting it to the _same_ pointer is superfluous or just duplication of information. Unless you want to do it for a particular purpose (like to be explicit), it is a bad idea - having duplicate info in a dataset leaves you with the risk of missing one copy when an update is necessary. BUT - what you can do with this mechanism is to point to a _different_ irt object. Either for a subset of your own infrastructure (like a regional PoP), or as a 1st level contact for your downstreams. And those downstreams can update the contact info without having to bother you in your role as the _address_ bookkeeping :-) Wilfried.

3 2