- db-wg - mailman.ripe.net

Proposal for returning IRT objects
by Denis Walker 16 May '06

16 May '06

[Apologies for duplicate mails] Proposal for returning IRT objects Motivation ---------- The original proposal for the IRT object (ripe-254) did not make adequate provision for presenting the irt information to the user. A new query flag ("-c") was introduced. Because of the way this flag was implemented and the objects it returned, it was not considered intuitive or helpful. It can also cause confusion. A discussion held at the RIPE 51 meeting decided that the original implementation was a misunderstanding of the requirements. For more information, see AOB in the Database Working Group minutes: http://www.ripe.net/ripe/wg/db/minutes/ripe-51.html There was further discussion at the RIPE 52 meeting, details of which can be found at: http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00052.html Objectives ---------- - To increase the availability of the irt information to users. - To promote the use of the IRT object. - To make it easier for third party tool writers to find the correct contacts. Background ---------- There has been confusion in the past about the implementation of the IRT object. We have been studying the concept and looking deep into the whois query code. Our understanding of how this works now, and how the community wants it to work in the future, has changed. This proposal outlines the current behaviour and what we now understand to be the desired behaviour. Current behaviour ----------------- A standard query for address space returns the queried inetnum and related objects. This does not include an IRT object, even if it is directly referenced by the queried INETNUM object. By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still returned. By using the "-c" flag, an INETNUM object is returned with a referenced IRT object and objects related to this INETNUM. This may not be the INETNUM in the query. No ROUTE objects are returned. If no (less specific) INETNUM references an IRT object, nothing is returned. By using the "-rc" flags, the related personal objects are filtered out, including the IRT object. The only object returned is the referencing INETNUM object, which may not be the one in the query. So it is not possible to find IRT objects without returning personal objects related to the referencing INETNUM object. New behaviour ------------- A standard query for address space returns the queried INETNUM and related objects. This does not include an IRT object, even if it is directly referenced by the queried INETNUM object. This is the same as the current behaviour. We propose to change this default behaviour at the second stage of implementation (see Implementation below). By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still returned. A standard query for address space including the "-c" query flag returns the queried inetnum and related objects. This will also include an IRT object referenced by the queried INETNUM object or the closest less specific INETNUM object, if one exists. It will also still include any ROUTE objects. By using the "-rc" flags, the related personal objects are filtered out. The IRT object will still be returned along with any ROUTE objects. When using any other address space query flags (lLmMxb) or querying for other object types, query behaviour remains the same as the current behaviour. If the "-c" query flag is used, it will be ignored. Implementation -------------- We propose a two stage implementation. The majority of the address space queries are made without any specific flags. We therefore propose to change the behaviour to return an IRT object by default (if one exists) only at the second stage. For the first stage, we propose changing the behaviour of the "-c" flag and the "-rc" flag combination as described above. This should not make any fundamental changes to the way the queries work. Existing tools and scripts should not fail. The web query form on www.ripe.net will add the "-c" flag to address space queries, making it a default. This only occurs if no other address space query flags (lLmMxbc) are present. At the second stage, the query server will add the "-c" flag to any address space query that does not include any of the address space query flags (lLmMxbc). This will make standard queries return IRT objects by default. This second stage changes the current behaviour of queries. This may break some tools and scripts. We can mitigate this by providing new query flags or using existing ones in different ways so that the behaviour resulting from the first stage of implementation can be reproduced. Tool writers ------------ Currently any third party tools that use the "-c" flag to find IRT objects run the risk of being blocked for returning too many personal objects. With the new behaviour, the "-rc" flags can be used to return the IRT objects without the personal objects. If only the IRT object is needed, "-rc -T irt" can be used. Notes ----- Any references to INETNUM and ROUTE objects also imply INET6NUM and ROUTE6. A consequence of this change is the return of an object with no direct reference from the queried object. With grouping turned on (default without "-G"), we assume that the IRT object should be grouped with the queried INETNUM object. -- Denis Walker Software Engineering Department RIPE NCC

1 0

Draft Minutes of the RIPE 52 DB-WG meeting
by Nigel Titley 15 May '06

15 May '06

Please find enclosed the first rough draft of the minutes. Please check your action points and make corrections to me. Thanks Nigel <<DB-minutes.txt>>

10 17

Maintenance announcement
by Trudy Prins 15 May '06

15 May '06

[Apologies for duplicate mails] Dear Colleagues, On Thursday, 18 May 2006 the following services will be unavailable from 05:00 - 06:00 GMT: - RIPE Whois Test Database - Internet Registry Information Service (IRIS) Server - Routing Registry Consistency Check (RRCC) Database These services will be unavailable while we perform important server maintenance work. We apologise in advance for any inconvenience. If you have any questions or concerns about this, please e-mail: <ripe-dbm(a)ripe.net>. Regards, Trudy Prins User Support Coordinator Software Engineering Department

1 0

whois update service was paused
by Trudy Prins 11 May '06

11 May '06

[Apologies for duplicate mails] Dear Colleagues, Yesterday, we deployed several bug fixes for the whois server software. The fixes should improve ORGANISATION object name handling. During the work, the whois update service was paused for around two hours. We apologise for the inconvenience. If you have any questions or concerns about this, please e-mail <ripe-dbm(a)ripe.net>. Regards, Trudy Prins User Support Coordinator Software Engineering Department

1 0

clients statistics
by md＠Linux.IT 10 May '06

10 May '06

I'd like to see published on the RIPE web site statistics about the -V parameter used by whois clients to identify themselves to the server. Does this need a formal proposal or is something which NCC staff can just implement quickly? -- ciao, Marco

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 09 May '06

09 May '06

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 4 August 2006 Time: 0900 - 1700 Location: Warsaw, Poland And Date: Friday 1 September 2006 Time: 0900 - 1700 Location: Reykjavik, Iceland 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 course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/rr/ How to register: --------------------- You can register up to two people from your LIR for each course. (If there are places left nearer the time of the course, you can register more people). To register for this course, you can either use the LIR Portal at: https://lirportal.ripe.net/lirportal/training/course-list.html Or the online registration form on our website: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

RE: [db-wg] Draft Minutes of the RIPE 52 DB-WG meeting
by Nigel Titley 04 May '06

04 May '06

> No, after Manchester the agreement was to return the irt > record relevant > to the queried ip/network. > This is subtly different from the behaviour of -c, which may return a > less specific inetnum object if the irt record is referenced by it. And this, if I recall correctly was, at the heart of the argument in Istanbul Nigel

1 0

RIPE 52 Draft Minutes of the DB WG meeting (2nd Draft)
by Nigel Titley 04 May '06

04 May '06

Dear All, Well, I'm quite gratified that people actually read the minutes. Usually I circulate them on the mailing list and get no response at all. I think I've folded in most of the corrections and attach a 2nd version. Thanks to those who have made factual corrections. I published the minutes as quickly as I could so we could get them correct while things were fresh in our minds, hence the somewhat unpolished look. Once we've got the content right I'll do a final polish. All the best Nigel <<DB-minutes.txt>>

1 0

updated RIPE Whois Database User Manual
by Trudy Prins 04 May '06

04 May '06

[Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce the publication of an updated RIPE Whois Database User Manual. ripe-375 RIPE Whois Database User Manual: Getting Started The content has been revised and updated and we have improved the wording to make it clearer. We have also added extra information about 'webupdates'. You can find the document at: http://www.ripe.net/ripe/docs/db-start.html Regards, Trudy Prins User Support Coordinator Software Engineering Department RIPE NCC

1 0

yet another irrtoolset replacement, 1.0
by md＠Linux.IT 25 Apr '06

25 Apr '06

I released version 1.0 of my routers configuration generator. It can generate the complete BGP configuration (neighbor statements, route maps, prefix and as-path lists) of peering or customer-facing routers using RPSL data, a local configuration file and a configuration template based on the popular Template::Toolkit perl package. Currently I only provide an IOS configuration template, but it should be easy to write one for JUNOS (patches are welcome!). I know that it's being used in production by several ISPs in the RIPE and APNIC region, so if you are not satisfacted by irrtoolset I think it's worth some consideration. It can be downloaded from http://www.linux.it/~md/software/rpsltool-1.0.tgz and is free software released under the terms of the GPL. (I think that I advertised it enough, so future releases will be announced on the project mailing list.) Major changes since the last public release: Modularized and cleaned up the code. Added the routesdiff program (formerly part of my cisco-tools package), to show which routes are actually not being accepted from a peer. Added the testpeerfilter program, to test the effect of a filter on a peer without actually loading it on the router. Added the nagpeer program, to automatically generate reports of bugs in the RPSL objects published by a peer. Added the rpslexpand, to quickly perform RPSL expansion from the command line. Added the findextraobjs program, useful to identify obsolete entries in peers configuration files. Added documentation. -- ciao, Marco

2 2