- db-wg - mailman.ripe.net

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

Proposal: Abuse-C as a Reference
by Ulrich Kiermayr 07 May '04

07 May '04

Hello, To put together a Proposal for how a Referece solution could be done . This abuse-c inherits all the features of irt as well, resulting in just one object for this area [Like in tech-c which is also not fine-grained like having something for routing, something for hardware, for peering, for .....] What can be done to have the 'abuse-mailbox' like in Randy/niall's proposal would be the Role/Person object: This would also make it easier to reference existing data, i.e. the one Person NOC where the local guru is admin and tech and abuse. For example: inetnum: 131.130.7.32 - 131.130.7.47 netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK3 tech-c: UK3 abuse-c: UK3 mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr(a)univie.ac.at 20040506 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 663 8174818 e-mail: Ulrich.Kiermayr(a)UniVie.ac.at abuse-mailbox:abuse@uk.atat.at # up to disc. nic-hdl: UK3 mnt-by: UK-MNT notify: Ulrich.Kiermayr(a)UniVie.ac.at changed: Ulrich.Kiermayr(a)UniVie.ac.at 20020723 source: RIPE --------------------------- Proposed Templates: [Changes are denoted by the <--] Add abuse-c to the objects where we need it (note that i have removed mnt-irt there) inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] aut-num: [mandatory] [single] [primary/look-up key] as-name: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] member-of: [optional] [multiple] [ ] import: [optional] [multiple] [ ] export: [optional] [multiple] [ ] default: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- notify: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 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] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] <-- encryption: [optional] [multiple] [ ] <-- trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] 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] [ ] For the consistency of the system one shoud add reference protection to the mntner too in that implementation. mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] 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] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 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). Query behaviour: -) 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). -) Change the -c flag to use abuse-c instead of mnt-irt. I hope that makes some sense. 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

3 14

draft agenda (V3) for DB-WG meeting, RIPE 48, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 04 May '04

04 May '04

Dear DB-WG community, this should be the final version (2) of the draft agenda for the DB-WG meeting at RIPE48 in Amsterdam, NL. Changes: - meeting schedule for 2005 - usability of RAToolSet, RPSLng checker compatibility Wilfried. ++++++++ [ slot Nr.1 ] A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (Shane K., RIPE NCC) [~20 min] C. ERX Phase 3 (Leo V., RIPE NCC) [~15 min] D. Value "ZZ" for country: attribute (Engin G., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status [~30 min] . report by Andrew Newton, VeriSign . follow-up by RIPE NCC [ slot Nr.2 ] F. support for works of art (Nigel T., FLAG TC) [~10 min] . poetry | haiku | ??? G. irt: / abuse: [60+ min] . proposal by Niall O'R. & Randy B. . statistics by Marco H. H. RAToolSet & RPSLng (WW144) [~10 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 4-MAY-2004 14:09:08 UTC

1 0

draft agenda (V2) for DB-WG meeting, RIPE 48, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 30 Apr '04

30 Apr '04

Dear DB-WG community, below please find Version *2* of the draft agenda for the DB-WG meeting at RIPE48 in Amsterdam, NL. Changes: - the CRISP item was confirmed by Andrew Norton, as well as the follow-up by the RIPE NCC - proposal to better support works of art in the DataBase poetry or just haiku? text-only (IDN-style??) or multi-media? - a sub-item added in A. to find out if coordination is needed for "remote participation" and maybe the Wiki stuff. Looking forward to see many of you again in Amsterdam! Wilfried. ++++++++ [ slot Nr.1 ] A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) B. DB Operational Update (Shane K., RIPE NCC) [~20 min] C. ERX Phase 3 (Leo V., RIPE NCC) [~15 min] D. Value "ZZ" for country: attribute (Engin G., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status [~30 min] . report by Andrew Newton, VeriSign . follow-up by RIPE NCC [ slot Nr.2 ] F. support for works of art (Nigel T., FLAG TC [~10 min] . poetry | haiku | ??? G. irt: / abuse: [60+ min] . proposal by Niall O'R. & Randy B. . statistics by Marco H. Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 30-APR-2004 09:40:06 UTC --------------------------------------------------------------------------------

1 0

Re: [db-wg] Action item 47.2: Proposal for Adding Abuse Contact
by Wilfried Woeber, UniVie/ACOnet 26 Apr '04

26 Apr '04

>As a starting point, let's take (approximations to) MarcoH's RIPE-47 >statistics. > >Number of inet[6]num objects: > 10**6 >Number of inet[6]num objects with IRT: > 10**3 (not significant) This simple counting approach is potentially VERY misleading, as it is not the sheer _number_ of individual entries which should be counted, but the _size_ of the address blocks covered in this hierarchy. On top of that, there's the possibiltiy to use the hierarchy to e.g. provide a "1st-line" contact for an individual address block AND a fallback or upstream for the encompassing block. Marco, would it be reasonably easy for you to extract this additional piece of statistics data? Wilfried.

3 3

Announcement Routing Registry Training Courses
by RIPE NCC Training 22 Apr '04

22 Apr '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 follow ing 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: Thursday 24 June 2004 Time: 0900 - 1700 Location: Stockholm, Sweden AND: Date: Friday 9 July 2004 Time: 0900 - 1700 Location: London, United Kingdom AND: Date: Friday 6 August 2004 Time: 0900 - 1700 Location: Amsterdam,the Netherlands AND: Date: Tuesday 10 August 2004 Time: 0900 - 1700 Location: Tehran, Iran ********************************************************************* 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

draft agenda (V1) for DB-WG meeting, RIPE 48, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 21 Apr '04

21 Apr '04

Dear DB-WG community, below please find Version 1 of the draft agenda for the DB-WG meeting at RIPE48 in Amsterdam, NL. In order to refine this 1st draft, I'd like to ask - Andrew Newton to confirm - or cancel - the CRISP item (I was told about that indirectly by NCC staff), and tell us a bit about time-slot length and content, - Niall and Randy: who's going to present the abuse proposal, - every individual or group mentioned in the list of topics to please check the lengh of the timeslot allocated and/or reply _to me privately, pls._ with information missing or any change requests. Pls. let me know asap if I missed any of the topic proposals and/or requests. If so, it was not done on purpose!! Looking forward to see many of you again in Amsterdam! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes B. DB Operational Update (Shane K., RIPE NCC) [~20 min] C. ERX Phase 3 (Leo V., RIPE NCC) [~15 min] D. Value "ZZ" for country: attribute (Engin G., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status [??? min] . report by Andrew Newton, VeriSign [t.b.c.] . follow-up by RIPE NCC [t.b.c.] F. irt: / abuse: [60+ min] . proposal by Niall O'R. & Randy B. . statistics by Marco H. Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 21-APR-2004 12:56:30 UTC

1 0

ORGANISATION objects in the RIPE Whois Database
by DB-News 19 Apr '04

19 Apr '04

Dear Colleagues, (apologies for duplicate messages) The RIPE NCC is pleased to announce that as of 17, April 2004, a new type of object, the ORGANISATION object, is available in the RIPE Whois Database. You can find more information about the ORGANISATION object at: http://www.ripe.net/db/organisation.html As part of the transition process, the RIPE NCC has: - created ORGANISATION objects for LIRs (around 4000 ORGANISATION objects) - updated LIR allocation objects to include "org:" attributes pointing to these new ORGANISATION objects (around 6500 INETNUM/INET6NUM objects) LIRs can update parts of their ORGANISATION objects through the ORGANISATION Object Editor available through the LIR Portal: https://lirportal.ripe.net/lirportal/index.html Please contact <ripe-dbm(a)ripe.net> for any questions. Best Regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

ANNOUNCEMENT Maintenance on Whois Server Regarding ORGANISATION Object
by DB-News 15 Apr '04

15 Apr '04

Dear Colleagues, [apologies for duplicate messages] On Saturday April 17, 2004, the RIPE NCC will perform maintenance work on the whois server. The aim of the maintenance is to upgrade the whois server to add support for a new object type, the organisation object. The maintenance is scheduled to start at 8:00 UTC (10:00 Amsterdam time) and expected to last around 10 hours. During the maintenance: - e-mail updates to <auto-dbm(a)ripe.net> will be queued to be processed after the maintenance - webupdates and syncupdates interfaces will NOT be available - whois query service will NOT be interrupted The maintenance work will consist of: - upgrading the whois software - creating ORGANISATION objects for LIRs - updating LIRs' allocation objects to have "org:" attributes pointing to these new ORGANISATION objects. We are sorry for any inconvenience this may cause. Please contact <ripe-dbm(a)ripe.net> for any questions. Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

Re: [db-wg] Action item 47.2: Proposal for Adding Abuse Contact
by Wilfried Woeber, UniVie/ACOnet 14 Apr '04

14 Apr '04

>To be sure, last meeting I had the count on the number of inet(6)num >objects having a mnt-irt and the number having a remarks: *abuse* >attribute. > >The request is to extend this on the actual number of IP-addresses covered >by both methods ? Correct, 'cause the single entry you can obtain by asking for > whois -h whois.ripe.net -cr 193.171.2.3 inetnum: 193.170.0.0 - 193.171.255.255 [ ... ] status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT mnt-irt: IRT-ACOnet-CERT [ ... ] actually covers a /15 range... > I will try to extend my script (grep | wc -l) a bit to >get this info, hopefully during next weekend but at least in time for the >next meeting. thanks! >Grtx, > >MarcoH Wilfried.

1 0

call for agenda items, DB-WG, RIPE48 @AMS
by Wilfried Woeber, UniVie/ACOnet 14 Apr '04

14 Apr '04

Dear DB WG! Our next meeting is scheduled for less than a month from today, so it is time to ask for agenda items for the draft agenda. Support items for the logistics will be provided by Nigel T. and myself, the meet on the bones should be suggested from "your" end:-) Looking forward to meet many of you in Amsterdam! 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or is it ::1 ?)

9 29

new release of ripe_wrap
by TAYON, Julien 06 Apr '04

06 Apr '04

Hello, I am pleased to annouce a release of a new version of neuf-telecom ripe_wrap tool. The use is to actually see if you are between 50% & 100% of the IPv4 assingment request you made to the RIPE, and to help you spot netname for which you have declared more than the AW (to some limitations though). It gives you a synthetic view of your use per inetnums & netnames & registrar... It crosses Lirportal information on IPv4 assignement, with direct query on the whois database. There is now : - a home page ; - a mailing-list ; - a CVS ; - a quite explicit documentation... http://ripe.est-unique.net I just created the domain, and it has not yet been propagated worldwide :) It is not perfect and can be largely improved. Friendly, -- julien.tayon(a)neuf.com +33 (0)1 70 18 14 45 Gestion des adresses IPs, BU Data n9uf telecom 40 - 42 Quai du Point du Jour 92659 Boulogne Billancourt

1 0

Beta release of Whois S/W with organisation object
by Engin Gunduz 06 Apr '04

06 Apr '04

Dear Colleagues, [Apologies for duplicate mails] We have made available the beta version of RIPE Whois Software that supports the organisation object. You can find it at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0-org-obj-beta.tar.gz Plese note that the software has been tested only on Solaris 8 environment. Please contact me at <engin(a)ripe.net> for any questions/comments. Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

New database Features
by Denis Walker 25 Mar '04

25 Mar '04

Dear Colleagues, [Apologies for duplicate mails] We have recently installed an updated version of the Whois software and Database update software. As well as some bug fixes there are three new features in the Database software. X.509 ----- This is now fully implemented. You are able to create the new X.509 KEY-CERT objects and reference these in the "auth:" lines of a maintainer. You can now use X.509 authentication with all our update methods: mail, syncupdates and webupdates. There is a link to the X.509 enabled webupdates script from the RIPE Whois Database page of the RIPE NCC web site: http://www.ripe.net/db/index.html The direct link is: https://www.ripe.net/perl/webupdates-x509.pl For documentation please refer to: http://www.ripe.net/db/x509.html You may also wish to check some other updated documents on security of objects: http://www.ripe.net/db/security.html http://www.ripe.net/db/Maintainer_Creation_Procedure.html http://www.ripe.net/db/pgp.html CIDR notation for inetnum creation. ---------------------------------- We now allow the use of CIDR notation when creating INETNUM objects. The CIDR string is replaced by the expanded range notation before the object is processed. This feature is ONLY permitted when creating an object. For example if the following object is submitted to the RIPE Database: inetnum: 1.2.0.0/16 before any further processing is done it will be converted to: inetnum: 1.2.0.0 - 1.2.255.255 A warning message will be added to the acknowledgement reply. It is now standard policy to add a warning if any changes are made to the submitted data. Prefix range lists for "mnt-routes:" ---------------------------------- The "mnt-routes:" attribute's syntax has been extended to allow prefix range lists. This will enable people to specify which maintainer has to authorise the creation of the specific routes. As an example: mnt-routes: MY-MNT { 20.34.0.0/1617-18, 20.34.0.0/16^- } mnt-routes: NOT-MY-MNT { ANY } Support for the previous syntax is unchanged. The extended syntax complies with RFC2725 which can be found at: ftp://ftp.ripe.net/rfc/rfc2725.txt For questions and comments please contact <ripe-dbm(a)ripe.net>. Best regards, -- Denis Walker RIPE NCC Software Engineering Department

1 0

Announcement: Changes to the ripe-dbm and auto-dbm acknowledgments
by Timur Bakeyev 23 Mar '04

23 Mar '04

Dear Colleagues, After 24 of March acknowledgments will be sent to all incoming mails send to <ripe-dbm(a)ripe.net>. This feature was promised to the community on the last RIPE meeting. Addition of this new feature has required changes to the way how acknowledgments are sent from <auto-dbm(a)ripe.net>. We realize that such a change may have an impact to the way how mails are processed by our customers, so here is the short description of the key changes: * All the acknowledgments will be sent with the 'Return-Path:' set to <>. * 'From:' field will point to the unattended mail address <unread(a)ripe.net>. This should protect us from the replies of the automated mail tools and mailer daemons. We are using the 'Auto-Submitted:' field to denote auto generated mail responses, as it is proposed in the draft RFC "Recommendations for Automatic Responses to Electronic Mail", available at: ftp://ftp.ripe.net/internet-drafts/draft-moore-auto-email-response-05.txt The widely recognized 'Precedence: bulk' mail header is used as well. There are two types of acknowledgments - ACK and NOTIFY, that are send by <auto-dbm(a)ripe.net>. ACKs are sent as the direct result of the updates of the Whois data. NOTIFYs are sent in the case when the updated object has 'notify:' or 'mnt-by:' fields or when an update fails to pass authorization check. Please consult the RIPE Database Reference Manual for farther details: http://www.ripe.net/ripe/docs/databaseref-manual.html#3.5 For the mail of ACK type: * The 'Reply-To:' field will be set to the <auto-dbm(a)ripe.net>. * 'Auto-Submitted:' will be set to the 'auto-replied' value. For mails of NOTIFY type: * The 'Reply-To:' field will be set to <ripe-dbm(a)ripe.net>. * 'Auto-Submitted' field will be set to the 'auto-generated' value. With best regards, Timur Bakeyev RIPE NCC

1 0

IRT object creation is easy
by Jeroen Massar 17 Mar '04

17 Mar '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, For the sake of promotion of the IRT object and for checking out if it really is easy creating it I requested an IRT object from RIPE, who have assigned it without much problems. The main problem was me not filling the form in correctly and after that being so stupid not having added the correct PGP key *whistle* and indeed it won't authenticate if the mnt-irt authentication is not satisified, thus that part is now also succesfully tested. Anyhow, it *is* easy getting it and if we (SixXS) can get it, then any ISP should be able to get it. Almost all the inet6nums assigned to the SixXS project now have a mnt-irt on their /40's, the other POPs will follow. Thus I can now say that: $ lftp ftp://ftp.ripe.net/ripe/dbase/split $ ls - -rw-r--r-- 1 ftpuser ftpgroup 176490 Mar 16 01:42 ripe.db.inet6num.gz $ get ripe.db.inet6num.gz $ gunzip ripe.db.inet6num.gz $ grep -cE inet6num ripe.db.inet6num 4206 $ grep -cE "mnt-by:.*SIXXS-MNT" ripe.db.inet6num 1872 1872/4206*100% ~= 44.50% of the inet6num's is now protected by the IRT-SIXXS object by adding about 10 mnt-irt attributes to 10 different objects. $ grep -c "mnt-irt:" ripe.db.inet6num ripe.db.inet6num 102 Add 6 to that at the moment, as the updated objects are not in this splitted file yet. For that matter, there are also other ISP's adding mnt's: $ cat ripe.db.inet6num |grep -E mnt-irt | sort | uniq -c 21 mnt-irt: IRT-AA 1 mnt-irt: IRT-ACOnet-CERT 49 mnt-irt: IRT-DFN-CERT 5 mnt-irt: IRT-ITGATE 2 mnt-irt: IRT-SPEEDKOM1 1 mnt-irt: IRT-UK 23 mnt-irt: irt-CERT-NL It would also be quite fast to deploy more mnt-irt's by making the field mandatory for new allocations forcing ISP's to make use of the object. Because of the above I don't see a reason for a abuse-c or similar object. If there is a need for adding things like 'spam' or 'ddos' etc then these should be added to the IRT object and not to a new one. Now everybody go request an IRT object and get it over with. In total it will probably cost you a max of 2 hours and I think that can be really worth it as when it is being used we can then tell abuse tool writers where to look. Handy docs: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-db-irt.pdf http://www.ripe.net/ripe/docs/irt-object.html Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFZd8QAAxRMAn22KiziDgieySrdDQele+peb DXCPAJ9FwYSfaZy9XeU3SPK0gqkYM2a5LA== =ZDFN -----END PGP SIGNATURE-----

7 11

Re: [db-wg] IRT object creation is easy
by Wilfried Woeber, UniVie/ACOnet 17 Mar '04

17 Mar '04

>I wouldn't say this. I sent request day ago and unil now I didn't >get any response from people approving it. "... didn't get ANY response ..." I guess you should have got an automatic reply, with a ticket number?! Wilfried.

1 0

person objects update
by Pieterjan d'Hertog 17 Mar '04

17 Mar '04

Dear all, Just a sugestion Could it be possible to include the full name of the person in the detailed explanations of the ripe-dbm robot when creating new person objects in the ripe database ? If I remember well, in the previous version this was done ? This will be very usefull to more easily parse the results of an update and to import them in our own database. Example : The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] CS2321-RIPE ***Info: Authorisation for [person] CS2321-RIPE using mnt-by: authenticated by: SKYNETBE-MNT Could be : Create SUCCEEDED: [person] Chris Sanders NEW nic-hdl : CS2321-RIPE Thanks, --- Pieterjan d'Hertog, Belgacom ANS/ROC Internet Expertise Center

5 9

SUCCESS: [New person: Test User]
by ripe-dbm＠ripe.net 16 Mar '04

16 Mar '04

> From: "Robert S. Plaul" <robert(a)plaul.de> > Subject: [New person: Test User] > Date: Tue, 16 Mar 2004 16:12:55 +0100 (CET) > Reply-To: robert(a)plaul.de > Message-ID: <Pine.LNX.4.58.0403161611570.3525(a)klendathu.crossline.org> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 1 Create: 1 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: [New, person:, Test, User] ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] TU107-RIPE ***Info: Authorisation for [person] TU107-RIPE using mnt-by: authenticated by: CROSSLINE-MNT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net> Regards, Robert S. Plaul -- RSP-RIPE

1 0

person objects update
by Pieterjan d'Hertog 16 Mar '04

16 Mar '04

Dear all, Just a sugestion Could it be possible to include the full name of the person in the detailed explanations of the ripe-dbm robot when creating new person objects in the ripe database ? If I remember well, in the previous version this was done ? This will be very usefull to more easily parse the results of an update and to import them in our own database. Example : The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] CS2321-RIPE ***Info: Authorisation for [person] CS2321-RIPE using mnt-by: authenticated by: SKYNETBE-MNT Could be : Create SUCCEEDED: [person] Chris Sanders NEW nic-hdl : CS2321-RIPE Thanks, --- Pieterjan d'Hertog, Belgacom ANS/ROC Internet Expertise Center

1 0