- db-wg - mailman.ripe.net

AfriNIC Transition Completed
by Axel Pawlik 23 Feb '05

23 Feb '05

Dear Colleagues, AfriNIC is the emerging Regional Internet Registry (RIR) for the African and Indian Ocean region. In preparation for its final recognition expected in April by ICANN, AfriNIC began operating as a fully functional RIR for the African region on 21 February 2005. LIRs in the AfriNIC service region can now request IP address space, AS Numbers and reverse delegation from AfriNIC and enter objects in the AfriNIC Whois Database. Details of the RIPE NCC to AfriNIC transition can be found at: http://www.ripe.net/info/resource-admin/afrinic/ If you have questions regarding the transition to AfriNIC, please contacts us at <afritrans(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

4 3

Proposed changes for abuse
by Shane Kerr 23 Feb '05

23 Feb '05

Dear Colleagues, We've gone over the changes discussed and agreed on for improving the ability to find abuse information in the RIPE database, and have come up with the following modifications. Please have a look. We will be making announcements once final agreement is done, and adding a URL to the banner and dbupdate messages. Two things did not make it into this proposal from our side. One is that we find the name "IRT" somewhat confusing, but we have no specific proposal to change it. The second is a proposal to change the order of objects in query results, which will be sent as a separate proposal, since it is not very related and might cause controversy. -- Shane Kerr Software Manager RIPE NCC Following discussions in the Database Working Group at RIPE 49, we have prepared a proposal to make changes to the whois server software. The changes we propose are: o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature, o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, ORGANISATION, INETNUM, and INET6NUM objects, o To provide an option to display only key attributes and abuse contacts, o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory, o To change the behaviour of the '-c' switch in whois queries. We will announce the changes on our website. We will also contact any third-party software developers who rely on the RIPE Database for abuse contact information. You can read the minutes from the Database Working Group discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00469.html (1) Adding the "abuse-mailbox:" Attribute We will add a new attribute to the following object types: INETNUM INET6NUM PERSON ROLE IRT ORGANISATION MNTNER This optional attribute will contain at least one e-mail address. It will tell users where to send abuse complaints or queries. (The proposed templates for the above objects are at the end of this document.) The description of the new attribute will be the same in all objects: abuse-mailbox: Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:". As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@localhost trouble: for abuse reports, not info@localhost nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE We will replace this with: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@localhost remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE (2) Hiding Attributes That Contain E-Mail Addresses Finding the right e-mail address for abuse reports can be confusing. There is currently no easy way to find this information in the RIPE Database. Users often send mail to every e-mail address they see in a query result. To avoid this, we will hide all attributes that contain e-mail addresses from the default output of a whois query for an address. When a user looks up an address, the results may include the following objects: INETNUM INET6NUM ROUTE ROUTE6 ORGANISATION PERSON ROLE By default, MNTNER objects are not shown, but they are often also queried to get contact information. For each of the object types, the following attributes contain e-mail addresses: INETNUM: notify, changed INET6NUM: notify, changed ROUTE: notify, changed ROUTE6: notify, changed ORGANISATION: e-mail, notify, changed PERSON: e-mail, notify, changed ROLE: e-mail, trouble, notify, changed For each address range returned, if there is at least one "abuse-mailbox:" attribute in any of the returned objects, the attributes mentioned above will be removed from the output. If there is no "abuse-mailbox:" attribute, only "notify:" and "changed:" attributes will be filtered out. If an attribute of an object is changed, a comment will be added, to avoid confusion. Users can turn off this suppression. To make this possible, we will implement a '-B' flag. As an example: $ whois 10.0.0.10 Might currently give the following result: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE After the change, the result will be: % Note: this output has been filtered. inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 nic-hdl: ME1-RIPE mnt-by: I-MNT source: RIPE To see the unmodified result, users should type in: $ whois -B 10.0.0.10 (3) Adding 'abuse output' Option To help authors of tools or users who are only interested in the abuse contacts for IP addresses, we will implement a brief output mode. If a user types '-b' when querying the RIPE Database, they will only see the key attributes of address ranges and the "abuse-mailbox:" attribute. This switch will also imply '-c', which requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It will only work with address space related queries. Here is an example: $ whois 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 abuse-mailbox: ripe-dbm-person@localhost source: RIPE So: $ whois -b 10.0.0.0 Will return: % Note: this output has been filtered. % Only primary keys and abuse contact will be visible. inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost This output will not generate valid objects, and there will be no object separators. If two ranges are returned after making a query, an object separator will be inserted between groupings. Therefore, the output will look like this: inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost (*) inetnum: 10.0.1.0 - 10.0.0.255 abuse-mailbox: ripe-dbm-person-2@localhost (*) Attributes marked by (*) are taken from the person object retrieved by a recursive lookup. (4) Modifications on the IRT Object We will change the template for the IRT object will be changed. You will no longer need a KEY-CERT object to create an IRT object. Currently, the template for the IRT object is: 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] [ ] "signature:" and "encryption:" attributes need existing key-cert objects. The Anti-spam Working Group asked us to make these objects optional. You can read an archive of this discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00452.html The template for irt objects will be: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [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] [ ] Therefore, the object below would be valid: irt: irt-someorg-zz address: address for the irt phone: +11 22 3344556 fax-no: +11 22 3344556 e-mail: contact@localhost admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@localhost 20050505 source: RIPE We will automate this process, so that help from the RIPE Database Management will no longer be necessary create IRT objects. (5) Changing the behaviour of '-c' option in whois queries Currently, the -c option requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It does not return any related IRT objects. This will change, so that -c will treat IRT objects as contacts and do recursive lookups on related IRT objects. Here is an example: $ whois -c 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . After the change, the result will be: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . irt: IRT-TEST . . (6) Modified Templates inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** 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-domains: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [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] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** 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] mnt-domains: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [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] 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] trouble: [optional] [multiple] [ ] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] 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] 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] abuse-mailbox: [optional] [multiple] [ ] ** 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] [ ] organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 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] abuse-mailbox: [optional] [multiple] [ ] ** 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] [ ] Rows that are marked with '**' are additions to the templates.

12 23

Announcement Routing Registry Training Courses
by RIPE NCC Training 21 Feb '05

21 Feb '05

------- 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 Services RIPE NCC **************************************************************************** COURSE DATES AND VENUES ======================== Date: Wednesday 18 May 2005 Time: 0900 - 1700 Location: London, United Kingdom AND: Date: Friday 17 June 2005 Time: 0900 - 1700 Location: Paris, France ***************************************************************************** REGISTRATION: To register for this Course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Training Services RIPE NCC

1 0

Re: [db-wg] whois_rip feature request, multiple inverse attribute queries needed
by Wilfried Woeber, UniVie/ACOnet 17 Feb '05

17 Feb '05

>To: av(a)nethead.de >CC: db-wg(a)ripe.net >Subject: Re: [db-wg] whois_rip feature request, multiple inverse attribute > queries needed >From: Havard Eidnes <he(a)uninett.no> >Date: Fri, 07 Jan 2005 16:59:42 +0100 (CET) > >> would it be possible to enhance the RDB query in a way that >> multiple inverse queries are possible?! I would like to be able >> to query objects which match a certain set of inverse >> attributes with only one whois-query. > >If I understood the question correctly, that's already possible. > >You can list the multiple attribute names (admin-c, tech-c, etc.) >separated by comma as the argument to the -i query option. > >Regards, > >- Håvard Supplying a list of arguments actually results in a logical .OR. operation. But at 1st reading, my interpretation of the request was a .AND. operation. I think we need more details, please! _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 5

Proposed changes for object ordering
by Shane Kerr 16 Feb '05

16 Feb '05

Dear Colleagues, As mentioned in the posting with the subject "Proposed changes for abuse", here is the proposal to change object ordering. As always, please have a look and discuss it here. -- Shane Kerr Software Manager RIPE NCC This is a proposal to display output differently, making recursive lookup results clearer. Currently, the software has a grouping algorithm that sorts objects by type. For example, if a query finds two INETNUM objects, such as: inetnum: 10.0.0.0 - 10.0.0.127 . . admin-c: PERSON1-RIPE tech-c: PERSON1-RIPE . . inetnum: 10.0.0.128 - 10.0.0.255 . . admin-c: PERSON1-RIPE tech-c: PERSON2-RIPE . . For a query, such as: $ whois 10.0.0.0 - 10.0.0.0.255 Here, the related PERSON/ROLE/ORGANISATION objects will also be returned, after being grouped into types, ending duplication. Therefore, the actual result will contain: inetnum: 10.0.0.0 - 10.0.0.127 inetnum: 10.0.0.128 - 10.0.0.255 person: PERSON1-RIPE person: PERSON2-RIPE This kind of output may be misleading. The user needs to find contact details by looking first at the "admin-c:" and "tech-c:" attributes, and then look them up in the PERSON/ROLE objects shown at the end of the list. This becomes time consuming as the number of objects returned increases. We will change the default output format. We will group objects by relevance. This change will give the following result for the same query: % Information related to '10.0.0.0 - 10.0.0.127' inetnum: 10.0.0.0 - 10.0.0.127 person: PERSON1-RIPE % Information related to '10.0.0.128 - 10.0.0.255' inetnum: 10.0.0.128 - 10.0.0.255 person: PERSON1-RIPE person: PERSON2-RIPE The changes explained in the section 'Hiding Attributes That Contain E-Mail Addresses' in the abuse proposal will apply to each grouping in turn. If only PERSON2-RIPE contains an "abuse-mailbox:" attribute, PERSON1-RIPE will not be filtered when it first occurs in the output, but it will be filtered upon its second occurrence. The 'traditional' output format of the whois server will still be possible, by using the '-G' option. Note: Another proposal could be to present the reordered output if the '-G' option is passed, otherwise to use the current ordering. This would leave the average user with the confusing output, and give the more advanced users the intuitive output. Making it an option would avoid potential problems with tools breaking, but some of the abuse changes will break tools so this may be a good time to change the default.

1 0

RE: [db-wg] whois_rip feature request, multiple inverse attribute queries needed
by Titley, Nigel 15 Feb '05

15 Feb '05

Joao Damas wrote: > Perhaps it is time to think about leaving the whois query syntax as it > is now and look at a different way of looking up things in RIR DBs > (based on crisp?). > The current RIPE whois syntax may not be the best but it has been > consistent for quite a few years and overloading it is likely to not > make things easier for casual users while it would be muddle things > for long time users I must say, I'm inclined to agree with Joao on this. Let's leave the RIPE whois syntax to enjoy its retirement in peace and concentrate on how to get the features we want in CRISP. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** 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

AfriNIC Transition
by Axel Pawlik 09 Feb '05

09 Feb '05

Dear Colleagues, AfriNIC is the emerging Regional Internet Registry (RIR) for the African and Indian Ocean region. In preparation for its final recognition expected in April by ICANN, AfriNIC will begin operating as a fully functional RIR for the African region from 21 February 2005. The RIPE NCC is committed to its members and has therefore created a structured transition for members moving from the RIPE NCC to AfriNIC. Details of the transition can be found at: http://www.ripe.net/info/resource-admin/afrinic/ If you have questions regarding the transition to AfriNIC, please contacts us at <afritrans(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

1 0

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 19 Jan '05

19 Jan '05

Shane Kerr wrote: > We also plan on having the POEM object type implemented before the > next RIPE meeting, with work on that beginning as soon as the abuse > changes are completed. Excellent.... this is the *really* important work. Glad to see you have it scheduled so promptly. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** 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 DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 19 Jan '05

19 Jan '05

Gentlefolk, Niall has pointed out some major inaccuracies in the draft minutes, which I have corrected. Apologies for this. However luckily none of the action points have been impacted. 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

3 2

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Wilfried Woeber, UniVie/ACOnet 18 Jan '05

18 Jan '05

Yesterday I had a chat with Rodney T. about the same thing. I'll work with the NCC to come forward with an update on progress. Wilfried. ______________________________________________________________________ From: "Titley, Nigel" <NTitley(a)flagtelecom.com> To: "'MarcoH'" <marcoh(a)marcoh.net>, db-wg(a)ripe.net Subject: RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0 Date: Mon, 17 Jan 2005 16:17:21 -0000 MarcoH wrote: >> [AP49.3 RIPE NCC] To produce a document detailing the programme for >> introducing the changes. >> >> [AP49.4 RIPE NCC] To implement the abuse-email: attribute in the >> irt, person and role objects. > > Not that I want to push people, but is there any progress on this > topic or can anybody from the NCC give some indication on when this > is expected to get done ? I would be expecting both of these to be complete by next meeting, in the absence of any response to the contrary by the Ripe NCC. Nigel --

1 0

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 17 Jan '05

17 Jan '05

MarcoH wrote: >> [AP49.3 RIPE NCC] To produce a document detailing the programme for >> introducing the changes. >> >> [AP49.4 RIPE NCC] To implement the abuse-email: attribute in the >> irt, person and role objects. > > Not that I want to push people, but is there any progress on this > topic or can anybody from the NCC give some indication on when this > is expected to get done ? I would be expecting both of these to be complete by next meeting, in the absence of any response to the contrary by the Ripe NCC. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** 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

CVS and Bugzilla for RIPE Whois Server
by RIPE Database Manager 17 Jan '05

17 Jan '05

Dear Colleagues, The RIPE NCC has the source codes of the RIPE Whois Database software available under CVS (a version control system) and is publishing the bugs via Bugzilla (a bug-tracking system). By doing so, this allows anyone to: * have early access to new features of the RIPE Database Whois Server Software and * submit patches to the RIPE Database Whois Server Software. It also provides an easy and accessible method for submitting and tracking bugs and enhancement requests. To accommodate this feature, a web interface is available to browse the source codes at: http://www.ripe.net/cgi-bin/cvsweb.cgi/whoisserver/ while you can submit and track bugs at: http://www.ripe.net/bugzilla/. Stable Source and Binary Releases are available at: ftp://ftp.ripe.net/ripe/dbase/software/. Getting the source codes: You should type the following commands to check out the latest source code under CVS: cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot login [ No password, so just press [ENTER] on password prompt ] cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot co whoisserver These commands apply to the command line version of the CVS client software. A directory of CVS clients is available at: http://dmoz.org/Computers/Software/Configuration_Management/Tools/Concurren… Any suggestions about the system can be directed to ripe-dbm(a)ripe.net . Best Regards, Related Links: More information about CVS is available at: http://www.gnu.org/software/cvs/#TOCintroduction More information about Bugzilla is available at: http://www.bugzilla.org/docs/ -- Can Bican RIPE NCC Software Engineering Department

1 0

whois_rip feature request, multiple inverse attribute queries needed
by Arnd Vehling 07 Jan '05

07 Jan '05

Hello, would it be possible to enhance the RDB query in a way that multiple inverse queries are possible?! I would like to be able to query objects which match a certain set of inverse attributes with only one whois-query. Right now i can only query one inverse attribute a time, which means i need to collect all objects which match one of the attributes and then sort out those who match both. This often results in very huge numbers of objects which i need to compare via a perl script. Would this enhancement be reasonable?! best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212

2 1

RIPE Whois Database maintenance
by Engin Gunduz 28 Dec '04

28 Dec '04

Dear Colleagues Apologies for any duplicate mails On Wednesday, 29 December 2004, we will perform maintenance on the RIPE Whois Database. After this, the RIPE Whois Database will support RPSLng. You can find more information about this at: http://www.ripe.net/db/news/rpslng-211204.html We plan to start the maintenance at 15:00 Amsterdam time (14:00 UTC). It will take around four hours. During this time, there will be no interruption to Whois queries, however: - You will not be able to make any updates to the Whois Database using either webupdates or the LIR Portal, - We will process any e-mail updates, sent to auto-dbm(a)ripe.net, after we complete the maintenance work. We apologise for any inconvenience this work might cause. Best regards Engin Gunduz RIPE NCC Software Engineering Department

1 0

Announcement: Policy Development Process in RIPE
by Rob Blokzijl 21 Dec '04

21 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

1 0

RPSLng in the RIPE Whois Database
by Shane Kerr 21 Dec '04

21 Dec '04

Dear Colleagues, Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng. RPSLng extends the Routing Policy Specification Language (RPSL) allowing description of IPv6 and multicast routing policies. It includes a new object type, ROUTE6, and new attributes, such as "mp-import:" and "mp-export:". RPSLng was submitted to the IETF to become an RFC. You can read the most recent draft at: http://www.radb.net/rpslng-08.html This change will not affect the current contents of the database. It is optional for any objects you maintain. The main differences for query users are as follows: - Currently a query for an IPv4 address or network may return INETNUM, ROUTE, and INET-RTR objects. A query for an IPv6 address or network can only return an INET6NUM object. After we put RPSLng into production, IPv6 queries will start to also return ROUTE6 and INET-RTR objects, if they are in the database. - Currently an inverse query (using the "-i" flag) for AUT-NUM objects may return ROUTE objects. After we put RPSLng into production, a query will return both ROUTE and ROUTE6 objects. If you want to limit your query, you can use the "-T" flag. For example, if you only want ROUTE objects returned to an inverse query, you can type: whois -h whois.ripe.net -T route -i origin AS3333 Please change your scripts if necessary. We will not move the contents of the RPSLng prototype Whois server to the RIPE Whois Database. You will have to create any objects that define your routing policy in the production RIPE Whois Database. You can update the RPSLng prototype Whois server until the start of January 2005. The query interface will be available until the end of January 2005. -- Shane Kerr Software Manager RIPE NCC

3 2

IRRToolSet maintenance moved from RIPE NCC to ISC
by Shane Kerr 17 Dec '04

17 Dec '04

Colleagues, We are happy to announce that the maintenance for the IRRToolSet has moved from the RIPE NCC to the Internet Systems Consortium (ISC). Starting now, ISC will support software development and maintenance of this suite. The new web page for this is: http://www.isc.org/sw/IRRToolSet/ The mailing list has been moved. The new address is <irrtoolset(a)isc.org>. E-mail will be forwarded from the existing mailing list (*). The RIPE NCC believes that ISC's software development model matches the IRRToolSet requirements, and that ISC will be a better home for the software. Operators and developers will have a set-up that is more typical to collaborative open source software, from a company that is experienced and focused on it. The RIPE NCC is grateful to ISC for agreeing to maintain this useful set of tools. We will continue to provide support for RIPE-specific portions and work with ISC in refining the software. -- Shane Kerr Software Manager RIPE NCC (*) When the mailing list forwarding began, Thursday 2004-12-16, filtering was removed. Shortly after the mailing list filtering policy was changed to "subscriber only". Apologies for the unwanted mail received during this period.

1 0

Re: [db-wg] Modifying the ACL for the whois server
by Nicolas Raux 06 Dec '04

06 Dec '04

when I try this set acl 127.0.0.1 deny=0 it seems ok (no error is returned) but I still can t query my local whois server here is what I get when I type : show acl ip maxprivate maxpublic maxdenials deny trustpass threshold maxconn 0.0.0.0/0 -1 -1 10 0 0 4 6 127.0.0.1/32 -1 -1 10 1 0 4 6 Found 2 nodes

2 1

Problems with ERX for 192.0.0.0/8
by leo vegoda 01 Dec '04

01 Dec '04

Dear Colleagues, An error in the software managing the ERX process for 192.0.0.0/8 resulted in the creation of INETNUM objects with incorrect contact information for registrations in this range. As a consequence, e-mail notifications were sent to incorrect contacts on 18 November. Errors made when registering the contact information in the database have now been corrected. Any user updates to these INETNUM objects or maintainers since 11 November have been undone. A new set of ERX notification e-mails will be sent to the relevant contacts and the schedule will be extended by two weeks. The completion date will now be 17 February 2005. We apologise for any inconvenience caused. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Whois referrals changed source IP
by Robert Martin-Legene 18 Nov '04

18 Nov '04

For those of you (TLD's only?) who receives whois referrals from whois.ripe.net and thought they would always come from 193.0.0.0/24, it now seems that even though whois.ripe.net is in that range, the referrals can come from at least 193.0.4.152 (as it does right now). For us, we only allow the -V3.2.0,$IP option (stating the origin IP) if from an "NCC IP#". For all other IP## using that option we would give an error. Our last request from 193.0.0.0/24 was received Nov 17 11:16:46. Would the NCC be kind enough to officially inform of which range(s) the requests can come from? (I doubt it's the entire 193.0.0.0/21, which are server networks.) (And to think that it was actually Verisign who mailed us to let us know they had a problem using our whois server, I find kind of funny). -- Robert Martin-Legène IT security manager DK Hostmaster A/S

2 1

Alex Dempsey/Vodafone is out of the office.
by alex.dempsey＠vodafone.com 09 Nov '04

09 Nov '04

I will be out of the office starting 08/11/2004 and will not return until 22/11/2004. I will be out of the office starting 08/11/2004 and will not return until 22/11/2004. For any urgent queries, please call me on +353 87 6227222, otherwise I will respond to your message on my return. Regards, Alex Dempsey ****************************************************************************** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie(a)vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G ******************************************************************************

1 0

RIPE DB tertiary whois server
by Daniel Roesen 09 Nov '04

09 Nov '04

Hi, whatever this server is... can you please keep this one in production and not switch back to primary/secondary? :-) Wow, this one is really fast... Regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 3

RIPE-NCC-LOCKED-MNT
by Ulf Kieber 01 Nov '04

01 Nov '04

Re everybody, I accidentially stumbled into the following: kieber@rocky /home/wheel/kieber> whois -r -T inetnum 213.72.34.0/29 % This is the RIPE Whois secondary server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html inetnum: 213.72.34.0 - 213.72.34.7 netname: RABUTLERCO27579SCH descr: RA Butler County Infant School country: GB admin-c: CL71-RIPE tech-c: CL71-RIPE status: ASSIGNED PA mnt-by: RIPE-NCC-LOCKED-MNT remarks: Maintainer RIPE-NCC-NONE-MNT removed and object remarks: LOCKED by the RIPE NCC due to remarks: deprecation of the NONE authentication scheme. remarks: Please visit the following URL to unlock this object remarks: http://www.ripe.net/db/none-deprecation-042004.html changed: cmorrison(a)rmplc.co.uk 20000803 changed: ripe-dbm(a)ripe.net 20040429 source: RIPE kieber@rocky /home/wheel/kieber> whois -r -T inetnum -l 213.72.34.0/29 % This is the RIPE Whois secondary server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html inetnum: 213.72.0.0 - 213.72.255.255 org: ORG-RMp1-RIPE netname: UK-RESEARCHMACHINES-20000316 descr: Research Machines descr: PROVIDER Local Internet Registry country: GB admin-c: RMS4-RIPE tech-c: RMS4-RIPE status: ALLOCATED PA notify: registry(a)rmplc.co.uk mnt-by: RIPE-NCC-HM-MNT mnt-lower: RMIFL-MNT mnt-routes: RMIFL-MNT changed: hostmaster(a)ripe.net 20000316 changed: hostmaster(a)ripe.net 20011127 source: RIPE kieber@rocky /home/wheel/kieber> I suggest RIPE NCC changes all occurences of mnt-by: RIPE-NCC-LOCKED-MNT in objects with status: ASSIGNED PA to mnt-by: <the value of mnt-lower in the one level less specific inetnum> In the above mentioned case mnt-by: RIPE-NCC-LOCKED-MNT should be changed to mnt-by: RMIFL-MNT RIPE NCC should never have to lock ASSIGNED PA inetnums. -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

1 0

ccTLD data in RIPE DB?
by Ulf Kieber 26 Oct '04

26 Oct '04

Re, weren't ccTLD domain registries supposed to remove their stuff from the database? Do a "whois -r -T domain -i notify notify(a)nic.gm". Which ccTLDs are still holding their registry data in the RIPE DB anyway? -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

3 3

RPSLng database deployment?
by Bernhard Schmidt 20 Oct '04

20 Oct '04

Dear all, having missed the last RIPE meeting I'm unfortunately somewhat out of date regarding this, but could someone please enlighten me about the current plans for deployment of RPSLng in the regular RIPE database? I am using rpslng.ripe.net, but unfortunately almost noone else does. Running a network without any sustainable prefix authorization sucks quite hard, it is a real pain to have to contact your upstream by mail if you have a new prefix (besides other things). Are there any problems with RPSLng currently? Thanks Bernhard

6 6