- db-wg - mailman.ripe.net

Re: NCC#2007121786 Customer number 106400
by RIPE NCC Billing Department 19 Feb '08

19 Feb '08

Dear Elena, We have updated the billing address and will resend the invoice there. However, you need to update the postal address of the registry via the LIR Portal (https://lirportal.ripe.net). -- Regards, Rabia Gawish RIPE NCC On Fri, 14 Dec 2007 11:09:51 +0300, Khortseva Elena wrote: > Dear All, > I would like to inform you about change registered address. > Registered address is > > Suite A > The Chambers > 5A The Square > Petersfield > Hampshire > GU32 3HJ U.K. > > Can you please re invoice the following invoice? > > #I0805322 dated 4/12/2007 > > I make apologize for late informing. > > > Best regards, > > Khortseva Elena > Manager,ReTN Ltd. > phone: +7 (495) 740-48-40 > fax: +7 (495) 740-48-41 > e-mail: khortseva(a)retn.net

2 2

Important change to RIPE NCC services
by RIPE Database Manager 03 Jan '08

03 Jan '08

[Apologies for duplicate e-mails] Dear Colleagues, On Wednesday, 27 February 2008, between 17:00 and 19:00 (UTC), RIPE NCC staff will replace the web server www.ripe.net. This change means there are some possible issues that you need to be aware of. The IP address of www.ripe.net will change on Wednesday, 27 February. If you have any software that connects to this website, you should ensure that the IP address is not hard coded. The change will also result in a new URL for the syncupdates service. Most of the client software that uses syncupdates should be able to handle HTTP redirects, return code 301. If your software does this, then it will continue to work, though it is still advisable that you configure your software to use the new URL. If your software cannot handle HTTP redirects, you will need to update the URL in your software before Wednesday, February 27, to continue using this service. We would also advise that you fully implement HTTP handling in your software to avoid any future problems. The current syncupdates URLs are: http://www.ripe.net/syncupdates http://www.ripe.net/syncupdates-test These will change to: http://syncupdates.db.ripe.net http://syncupdates-test.db.ripe.net There will be a period between Wednesday, 13 February, and Wednesday, 27 February, when both the new and old syncupdates URLs will be available. We apologise for any inconvenience this may cause. If you have any questions or concerns about this, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards, Agoston Horvath Software Engineer, RIPE NCC

1 0

ripe whois server on freebsd
by Matkhamtkha Brekher 03 Jan '08

03 Jan '08

my compilation of ripe whois server 3.3.0 has failed on freebsd 7.0-beta4 gmake[3]: Entering directory `/usr/home/ono/Desktop/whoisserver-latest/src/defs' mkdir -p /usr/home/ono/Desktop/whoisserver-latest/src/modules/rpsl && \ cd /usr/home/ono/Desktop/whoisserver-latest/src/modules/rpsl && \ RIPINCDIR="/usr/home/ono/Desktop/whoisserver-latest/src/include/" RIPLIBDIR="/usr/home/ono/Desktop/whoisserver-latest/src/" CC="gcc -DHAVE_CONFIG_H -I/usr/local/bind/include -L/usr/local/bind/lib -I/usr/include/openssl -I/usr/local/include/openssl" CFLAGS="-I/usr/home/ono/Desktop/whoisserver-latest/src/defs -I/usr/home/ono/Desktop/whoisserver-latest/src/defs -I/usr/local/bind/include -L/usr/local/bind/lib -I/usr/include/openssl -I/usr/local/include/openssl -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/home/ono/Desktop/whoisserver-latest/src/include/" gmake -f /usr/home/ono/Desktop/whoisserver-latest/src/defs/Makefile.syntax && \ touch syntax gmake[4]: Entering directory `/usr/home/ono/Desktop/whoisserver-latest/src/modules/rpsl' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/usr/home/ono/Desktop/whoisserver-latest/src/modules/rpsl' gmake[3]: Leaving directory `/usr/home/ono/Desktop/whoisserver-latest/src/defs' gmake[3]: Entering directory `/usr/home/ono/Desktop/whoisserver-latest/src' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/mysql -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/bind/include -L/usr/local/bind/lib -I/usr/include/openssl -I/usr/local/include/openssl -I/usr/local/include/c-client/ -I/usr/home/ono/Desktop/whoisserver-latest/src/modules/rpsl -I/usr/home/ono/Desktop/whoisserver-latest/src/include -I/usr/home/ono/Desktop/whoisserver-latest/src/include -I/usr/local/bind/include -L/usr/local/bind/lib -I/usr/include/openssl -I/usr/local/include/openssl -MT crypt-md5.o -MD -MP -MF ".deps/crypt-md5.Tpo" -c -o crypt-md5.o `test -f 'modules/au/crypt-md5.c' || echo './'`modules/au/crypt-md5.c; \ then mv -f ".deps/crypt-md5.Tpo" ".deps/crypt-md5.Po"; else rm -f ".deps/crypt-md5.Tpo"; exit 1; fi modules/au/crypt-md5.c: In function 'crypt_md5': modules/au/crypt-md5.c:28: error: 'MD5_CTX' undeclared (first use in this function) modules/au/crypt-md5.c:28: error: (Each undeclared identifier is reported only once modules/au/crypt-md5.c:28: error: for each function it appears in.) modules/au/crypt-md5.c:28: error: expected ';' before 'ctx' modules/au/crypt-md5.c:56: error: 'ctx' undeclared (first use in this function) modules/au/crypt-md5.c:68: error: 'ctx1' undeclared (first use in this function) gmake[3]: *** [crypt-md5.o] Error 1 gmake[3]: Leaving directory `/usr/home/ono/Desktop/whoisserver-latest/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/ono/Desktop/whoisserver-latest/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/ono/Desktop/whoisserver-latest' gmake: *** [all] Error 2 any suggestions? P.S. [~/Desktop/whoisserver-latest]$ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD]

1 0

Unreferenced person/role objects
by Denis Walker 03 Jan '08

03 Jan '08

[Apologies for duplicates] Dear Colleagues, The RIPE Data Protection Task Force asked the RIPE NCC to look at why so many unreferenced person/role objects are being created. We found that one organisation was responsible for about 80% of all objects that became unreferenced over the course of 2007. At the time of investigation, this same organisation was responsible for about 30% of all existing unreferenced objects in the RIPE Database. We contacted them and they responded very quickly. They gave the RIPE NCC permission to delete all these unreferenced objects, and they have now adjusted their procedures. Over the New Year period, when we expected the load on the RIPE Database to be quite low, we deleted 161062 person/role objects. You can see the drop in the graph here: http://www.ripe.net/projects/dbconstat/cons-unrefpero.html This problem was caused by deleting inetnum objects, but not deleting the referenced person/role objects. We would like to ask you to please check your own assignment procedures. As customers come and go and you delete or re-assign address space, please delete any person/role objects that are no longer referenced. In the long term, the RIPE NCC will implement an automatic clean-up process, but this may take some time to develop. Regards Denis Walker Business Analyst, RIPE NCC

1 0

Replicated global whois DB
by Hank Nussbacher 19 Nov '07

19 Nov '07

Not sure if this is the right place to ask but is there available software available to download the complete whois DBs of ARIN/RIPE/APNIC/LACNIC/AFRINIC and have it available offline for whois lookups? Thanks, Hank

2 4

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 12 Nov '07

12 Nov '07

[Apologies for duplicate e-mails] Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Monday 28 January 2008 Time: 09:00 - 17:00 Location: London, United Kingdom AND Date: Tuesday 5 February 2008 Time: 09:00 - 17:00 Location: Muscat, Oman AND Date: Friday 29 February 2008 Time: 09:00 - 17:00 Location: Milan, Italy AND Date: Friday 28 March 2008 Time: 09:00 - 17:00 Location: Amsterdam, Netherlands 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

Draft Minutes v1.0 RIPE 55
by Nigel Titley 26 Oct '07

26 Oct '07

Gentlefolk, Please find the first draft of the DB-WG minutes. Comments, as always, are welcome. Nigel Minutes Database WG RIPE 55 Amsterdam Draft 1 A. Administrative Matters * Welcome * Select a scribe (Nigel T) * Finalise agenda (Agenda accepted) * Approve minutes from RIPE 54 (Approved) [AP54.1 RIPE NCC] To go ahead with final implementation of whois IRT query behaviour (-c), within 4 weeks. Deployed on 1st August after testing. Complete. [AP54.2 RIPE NCC + Chairs] To check through and decide how to split the Database manuals into RIPE and non-RIPE documents. Placeholder document RIPE-419 now points to technical manual. Complete [AP54.3 RIPE NCC] To go ahead and investigate ensuring that all objects are maintained, including timeline and notifications. Submit proposal to the Working Group. Discussion continues on when to implement (hopefully soon). [AP54.4 RIPE NCC] To investigate the provision of a "white pages" facility for industry related persons. Ongoing [AP54.5 DP-TF] To analyse better the function of the country attribute in inetnum and inet6num. Possibly related to the restructuring of the addressing information. However still unclear. Suggested that it should be related to the ultimate point of management of the resource. Ongoing. [AP54.6 RIPE NCC] To summarise the discussion on orphaned objects and write up for the mailing list Ongoing. No objection to proceding with Phase 2 and 3 and removing the objects. [AP54.7 RIPE NCC] To prepare a plan for removal of the rev-srv attribute from the inetnum, inet6num objects. Ongoing B1. Database Update - Jos Boumans, RIPE NCC * Operational update (See presentation) * Status of CRYPT-PW retirement * Removal of orphaned objects B2. DB-Software Developmen Activities * restructuring of documentation set Now complete * modification proposals (maintainer to become mandatory) See presentation [AP55.1 RIPE NCC] Add the feature to the LIRPortal "allocation editor" to include the "irt-mnt" attribute. C. Follow-up on: * Task Force on Data Protection Issues Nothing further to report * Resource Certification Project Ongoing. Nothing concrete likely before next April. D. Improvements to the DB Software - Yasuhiro Shirasaki, NTT See presentation. (High availability IRR systems) This is important in relation to a research project on anti prefix hijacking. Used RIPE whois-server as base system due to its speed and scalability. Uses NDBCluster to provide high availability database. However current performance still not adequate. Memory and CPU upgrades should help (4 -> 8GB RAM). Will be implementing offsite redundancy soon. Coverage is basically for Japanese prefixes at the moment but will be extended. In use by several JP ISPs at the moment to filter hijacked prefixes. E. A Case for NRTM for IRR Updates - Raymond J., Elisa, FI * 1075 peering session, 509 unique AS:ses See presentation. Extensively peered, so aut-num object maintenance is an major overhead. Tool XIRR gives contact information, traffic and advertisement information NRTM needed in order to keep the local copy up to date. F. A Review of the "changed:" Attribute - Peter K., DEnic, DE * syntax, semantics, quality of info in changed: ? Problem with changed: attribute. If it is present (even historical copies) then no new changed: line is needed. This casts some doubt on the utility of the changed: line. It cannot be relied upon as a reliable change history of the object or even as the latest change of the object. It is suggested that the changed: attribute should be changed: maybe by enforcing a timestamp for non-null changes. Maybe just maintain the creation and last modification dates? What about ensuring accuracy (a timestamp to say "this record was accurate on this date"). What about data protection issues on personal data? It is possible to produce virtually any variant of this from the database. A full audit trail of object modifications is maintained within the database but is generally only produced in response to a court order. Note that hostmasters actually use these attributes despite their dubious value. [AP55.2 Peter K] To find out what the changed: line is used for and come up with a possible way forward. Will need coordination with the DP-TF. Y. Input from Other Working Groups and Task Forces * Contact Data Quality/Requirements Discussion [Anti-Spam-WG] Continue with this in the DP-TF * "Dot-Notation" for ASN32 [Routing-WG] Some people are not happy with the Dot-Notation for ASN32. Conflict with router RE parsing. No consensus in the Routing-DB so not a lot we can do. Very few ASN32s have yet been issued. However it not an insignificant change. IRRToolset has been patched to allow the dot. The Dot-Notation is still only a draft RFC so may not end up turning into a full RFC anyway. At least one major router vendor has already adopted the Dot-Notation. Z. A.O.B. * External object removal requests (Malcom H.) The issue here is where a legal request might arrive to remove an item from the DB. If this is likely to happen, how should the RIPE NCC respond? At present there is no law that might mandate this, but one might come along. The RIPE DB covers far more than the EU, and this could create a conflict of interest (or even a diplomatic incident). Important that all be aware that this sort of thing is being proposed by certain elements within the EU and we should perhaps think about this. There is clearly a job for the RIPE NCC communications group to make it clear to appropriate bodies what the function of the database actually is [AP55.3 RIPE NCC]. Current RIPE NCC policy on information requests is to first point to the public data, and then if more is required, then require a court order from a Dutch judge. We clearly need to discuss this, but it probably needs discussing in a wider scope but it is very important to have arguments prepared beforehand.

1 0

RIPE55 DB-WG Draft Agenda V2
by Wilfried Woeber, UniVie/ACOnet 24 Oct '07

24 Oct '07

Dear DB-WG folks, Chairpersons, "Meeting"! This is an updated draft (V2) of the proposed agenda for the DB-WG during RIPE55 in Amsterdam, October 2007. For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-55/meeting-plan.html Please note that, for our convenience, the time slot map became clickable for those sessions which have already submitted a (draft) agenda! Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from RIPE 54 . review of action list B1. Data Base Update (Jos B., RIPE NCC) [~30 min] . operational update . status of CRYPT-PW retirement . removal of orphaned objects (AP54.7) B2. DB-Software Developmen Activities . restructuring of documentation set . modification proposals (maintainer required, ...) C. Follow-Up on . Task-Force on Data Protection Issues [t.b.c.] . Resource Certification Project [t.b.c.] D. Improvements to the DB Software (Yasuhiro Shirasaki-san, NTT JP[~10 min] E. A case for NRTM for IRR updates (Raymond J., Elisa, FI) [~10 min] . 1075 peers, 509 unique AS:ses F. A review of the changed: attribute (Peter K., DEnic, DE) [~10 min] . syntax, semantics, quality of info in changed: ? Y. Input from other WGs and TFs . Contact Data Quality/Requirements Discussion [AS-WG] [t.b.c.] . "Dot-Notation" for ASN32 [Routing-WG] [t.b.c.] Z. AOB ________________________________________________________________________

1 0

New RIPE Database document
by Denis Walker 11 Oct '07

11 Oct '07

[Apologies for duplicates] Dear Colleagues, During the Database Working Group (DB WG) session at RIPE 54, it was decided to review the status of those RIPE Documents relating to the RIPE Database. Following discussion on the DB WG Mailing List, a proposal to address this issue was produced, which can be viewed at: http://ripe.net/ripe/maillists/archives/db-wg/2007/msg00162.html No concerns were raised and this proposal has now been implemented. This implementation has resulted in a new RIPE Document, ripe-419 "RIPE Database Reference Manual". This provides a brief introduction to the RIPE Database and references the new RIPE Database Document Library, which can be viewed at: http://www.ripe.net/db/docs.html This library references all the available documents concerning the RIPE Database and associated services. These documents will, in future, be kept up-to-date with all changes to database software and procedures. If you have any questions or concerns, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards Denis Walker RIPE NCC

1 0

RIPE 54 Minutes (2nd Draft)
by Nigel Titley 14 Sep '07

14 Sep '07

Following comments made offlist, I attach an updated copy of the minutes. The relevant changes are in the discussion of the country attribute. Nigel This email and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the sender of this email by sending a return email to the address above and then delete the e-mail and your response from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Any views or opinions presented are solely those of the author. Any statements made, or intentions expressed in this communication may not necessarily reflect the view of Easynet. No content herein will bind Easynet or any associated company unless confirmed by the execution of a formal contract by Easynet. Any figures or amounts given in this email are quotations only and are subject to change. Although Easynet routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Easynet makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). Easynet Limited a company incorporated and existing under the laws of England and Wales, with company number 2954343 and having its registered office at 44-46 Whitfield Street London, W1T 2RJ.

1 0

RIPE55 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 14 Sep '07

14 Sep '07

Dear DB-WG folks, Chairpersons, "Meeting"! This is the (very rough) 1st draft of an agenda for the DB-WG at RIPE55 in Amsterdam, October 2007. For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-55/meeting-plan.html Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda! Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from RIPE 54 . review of action list B. Data Base Update (N.N., RIPE NCC) [~30 min] . operational update . status of CRYPT-PW retirement . removal of orphaned objects (AP54.7) C. follow-Up on . Task-Force on Data Protection Issues [t.b.c.] . Contact Data Quality/Requirements Discussion [t.b.c.] . Resource Certification Project [t.b.c.] D. DB-Software Developmen Activities [~30 min] . restructuring of documentation set . modification proposals (maintainer required, ...) Y. Input from other WGs and TFs Z. AOB ________________________________________________________________________

1 0

Call for agenda items, DB-WG Meeting during RIPE55, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 30 Aug '07

30 Aug '07

Dear DB-WG folks, Planning activities for the next RIPE Meeting - RIPE55 in Amsterdam - have already started, thus this call for agenda items. Please submit (to the WG list or to me personally) your item requests or suggest topics for discussion to be included in the draft agenda! I plan to distribute the 1st version of the draft agenda during the first week of September. The DataBase-WG meeting is, as "usual" scheduled for Friday morning, October 26, 2007. The overall RIPE meeting outline is already available at http://www.ripe.net/ripe/meetings/ripe-55/meeting-plan.html The list of plenary presentations and the session archive may eventually become available at [- as of late August this page does not exist yet -] http://www.ripe.net/ripe/meetings/ripe-55/presentations/ See you in Amsterdam, Wilfried.

1 0

Proposal to re-structure the RIPE DB Software Documentation
by Wilfried Woeber, UniVie/ACOnet 30 Aug '07

30 Aug '07

Following up on discussions in eMail and personally with folks at the NCC who are responsible for maintaining and developing the DB Software, Jos and I would like to come forward with the following proposal, in order to - ease the burden and formal overhead of keeping the DB-SW Documentation up-to-date and in synch with the software development, to - remove the formal RIPE Document status from ripe-401, ripe-252, "ripe-draft" and ripe-402, and to - create a *new* "formal" RIPE Document which acts as an anchor for the (new or updated) set of documentation and as a cross reference to the relevant operational manuals. This new RIPE Document may also include procedure- related topics that might be of special interst regarding implementation of the software at the NCC. The big advantage of this approach is to help with keeping the software and the documentation in synch and up-to-date, even for non-fundamental changes, instead of having formal and stable "baseline documents" and - over time - a set of change notices. Or, worse, outdated documentation :-) I hope this approach does not raise any fundamental concerns with the community and I will put that topic onto the DB-WG's draft agenda for RIPE55, for feedback and an update on where we are. If you do see major problems or have objections, please let us know as soon as possible on the mailing list! Thanks, Wilfried.

2 2

Re: RIPE NCC Scheduled Network Maintenance - Tuesday, 28th August 2007
by James Aldridge 28 Aug '07

28 Aug '07

--On 23 August 2007 16:59:31 +0200 James Aldridge <james(a)ripe.net> wrote: > The RIPE NCC will perform planned network maintenance work on Tuesday, > 28th August 2007 between 17:00 and 18:00 (UTC). This work has been completed successfully. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0

RIPE NCC Scheduled Network Maintenance - Tuesday, 28th August 2007
by James Aldridge 23 Aug '07

23 Aug '07

Dear Colleagues, The RIPE NCC will perform planned network maintenance work on Tuesday, 28th August 2007 between 17:00 and 18:00 (UTC). We apologise for any inconvenience that this may cause. If you have any questions, please send an e-mail to <ops(a)ripe.net>. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training 16 Aug '07

16 Aug '07

------- [Apologies for duplicate e-mails] Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 14 September 2007 Time: 09:00 - 17:00 Location: Lisbon, Portugal AND Date: Friday 28 September 2007 Time: 09:00 - 17:00 Location: Tbilisi, Georgia AND Date: Thursday 8 November 2007 Time: 09:00 - 17:00 Location: Southampton, United Kingdom AND Date: Tuesday 13 November 2007 Time: 09:00 - 17:00 Location: Damascus, Syrian Arab Republic AND Date: Friday 16 November 2007 Time: 09:00 - 17:00 Location: Amsterdam, Netherlands AND Date: Monday 3 December 2007 Time: 09:00 - 17:00 Location: Barcelona, Spain Hosted by: CESCA: http://www.cesca.es/en/on/index.html AND Date: Friday 14 December 2007 Time: 09:00 - 17:00 Location: Athens, Greece 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

IM contact
by Max Tulyev 14 Aug '07

14 Aug '07

Hi! I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects. Is there any support? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

13 17

Fwd: Re: [db-wg] IM contact - addition
by Wilfried Woeber, UniVie/ACOnet 14 Aug '07

14 Aug '07

What I forgot to include explicitely, sorry for that... >From: Wilfried Woeber, UniVie/ACOnet <Woeber(a)CC.UniVie.ac.at> >[...] >> Is there any support? >> >At first glance from this end: NO. *this was worded in my role as a regular netizen, I was NOT wearing my WG-Hat* >[...] Wilfried.

1 0

New RIPE Database server deployed
by Katie Petrusha 17 Jul '07

17 Jul '07

Dear Colleagues, On 1 August 2007, we updated the RIPE Database so that IP queries return IRT objects by default. The following changes were deployed: * The "-c" flag behaviour has become the default for all IP queries. This means that when querying an IP address or range, any query not containing the "-L", "-l", "-M", "-m" or "-x" flags will return the IRT object referenced by the closest less specific inet(6)num (if such a reference exists) by default. * A new "-C" (uppercase) flag has been implemented to provide the old behaviour and ensure backwards compatibility. The behaviour of the "-c" flag itself has not changed, and there were no changes for those queries that include other IP flags ("-L", "-l", "-M", "-m" or "-x"). You may need to adjust the software that you use to query the RIPE Database. The test server test-whois-default-irt.ripe.net has been decommissioned. If you have any questions, please send an e-mail to <ripe-dbm(a)ripe.net>. -- Regards, Katie Petrusha Database department RIPE NCC

2 2

RIPE NCC Service Outage 09/07/2007
by Brian Riddle 17 Jul '07

17 Jul '07

Dear Colleagues, Due to a network switch problem, RIPE NCC experienced a temporary loss of service between 11:41 and 12:15 (UTC) today. This affected our layer2 network and our services were therefore unreachable during this period. We would like to apologise for any inconvenience this may have caused. Regards, Brian Riddle IT Manager RIPE NCC

1 1

Proposal - Maintaining person, role and domain objects
by Denis Walker 11 Jul '07

11 Jul '07

[Apologies for duplicate mails] Dear Colleagues, As a result of discussions during the Database Working Group session at RIPE 54, the RIPE NCC has nine proposals and implementation plans to present to the community. Although most of them are now in the final stages of preparation, we will send them out one at a time over the next few weeks for consideration by the community. The first one concerns maintaining all objects in the RIPE Database, which followed from a recommendation from the Data Protection Task Force (DP TF) (see below). We have already had some preliminary discussions about this with the DP TF. They provided the RIPE NCC with some very useful feedback, which is incorporated in this proposal. Regards Denis Walker RIPE NCC Maintaining person, role and domain objects ------------------------------------------- * Introduction * Proposal * Illustrations of how the checks work - New startup - Closing down - Modifying existing data * Implementation - Stage 1 - Stage 2 - Stage 3 * Statistics Introduction ------------ It was agreed at RIPE 54 that the "mnt-by:" attribute would be made mandatory on all objects. Currently, for person, role and domain objects, "mnt-by:" is optional. Making "mnt-by:" mandatory on person objects raises two clear issues: 1. It creates a chicken and egg situation between person and mntner objects. 2. Many person objects are not changed for years, so any change to syntax may take a long time to be reflected in the database. Many un-maintained person objects could therefore remain so for many years. Proposal -------- Making "mnt-by:" mandatory on role and domain objects does not cause any technical difficulties. To address all the issues relating to the person objects, we suggest a slightly different approach. 1. Make "mnt-by:" mandatory in person objects. 2. Provide a mechanism in dbupdate to handle the startup case where a new person and mntner objects are required. 3. Provide a mechanism in dbupdate to handle the closing down situation where the last person and mntner objects are to be deleted. 4. Extend the referential integrity checks so that a person object cannot be referenced unless it is maintained, except in a mntner object. 5. Extend the referential integrity checks so that a mntner object cannot be referenced unless the person objects it references are maintained. This does not include the cyclic case of a person and mntner object referencing each other. The referencing checks sound complicated in words, but are actually quite simple. The illustrations below explain how it works in practice. This approach has a number of advantages: 1. It accommodates the chicken and egg situation. 2. We already do referential integrity checks. Whenever there is a reference to a person object, the database software checks if the person object exists. We only have to extend this check to see if the person object is also maintained. 3. Whenever there is a reference to a mntner object, the database software checks if the mntner object exists. We only have to extend this check to see if the person objects referenced by the mntner are maintained. 4. Each time any other object (say an inetnum or aut-num) is modified, the referenced person objects need to be maintained. If not, the update will fail. This will not prevent anyone from working. If they are going to modify an inetnum object, they must be authorised to do so. They can apply the same mntner to any un-maintained person objects. This encourages users to maintain the existing person objects. A CGI script may be provided to make this process simple and quick if it is considered to be helpful. 5. No un-maintained person object can be linked to the white pages to avoid deletion. (The white pages will be explained in a later proposal.) Illustrations of how the checks work ------------------------------------ New startup Send an update message to dbupdate to create a person object and a mntner object. These must be the first two objects in an update message, in any order. The references to each other must also be in place. The database software will accommodate this. person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE mnt-by: aardvark-mnt notify: denis(a)ripe.net changed: denis(a)ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis(a)ripe.net auth: X509-1 notify: denis(a)ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis(a)ripe.net 20040225 source: RIPE The update software will recognise that the first person/mntner object references a non-existent mntner/person object. It will check that this referenced object is next in the update message. If it is, the "mnt- by:" attribute will be removed from the person object. The person and mntner objects will be created, and then the person object will be modified to add back the "mnt-by:" attribute. The objects are now fully configured and can be used. The person object can be referenced by any other object where a nic-hdl is referenced. It can also be linked to the white pages. The mntner can be used to protect any data in the database. If the non-existent referenced object is not next in the update message then an error message will be generated and the update will fail. This is the current behaviour. Closing down The same situation occurs when closing down and deleting all the data. It is possible to delete all data except for the last person and mntner objects in the normal way. To delete these last two, send them together in an update message, both marked with the "delete:" pseudo attribute. Only these two objects should be in the update message. The update software will recognise that the first person/mntner object to delete is referenced in a mntner/person object. It will check that this referencing object is next in the update message and also marked for deletion. If so the person object will be modified first to remove the "mnt-by:" attribute. The mntner object will then be deleted, followed by the person object. Modifying existing data Suppose some data is to be modified and there is a reference to an un- maintained person object. Suppose you already have this data in the database: inetnum: 193.0.0.0 - 193.0.7.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands remarks: Used for RIPE NCC infrastructure. country: NL admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PI mnt-by: AARDVARK-MNT mnt-lower: AARDVARK-MNT changed: bit-bucket(a)ripe.net 20060221 source: RIPE person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE notify: denis(a)ripe.net changed: denis(a)ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis(a)ripe.net auth: X509-1 notify: denis(a)ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis(a)ripe.net 20040225 source: RIPE The inetnum and mntner objects both reference a person object that is not maintained. This situation can continue for the foreseeable future with no problem. The situation becomes problematic when some data needs to be changed. An attempt to modify the inetnum object will fail. This is because it references a person object that is not maintained. It also references a mntner object which references un-maintained person objects. (This will only happen in stage three of the implementation) These person objects will have to be maintained before the inetnum object can be modified. A CGI script will be provided to allow this to be done quickly and easily. When all referenced person objects are maintained, the original update can be resubmitted and will proceed. Implementation As with the CRYPT-PW deprecation this will have a staged rollout. Stage 1 * No new person, role or domain objects can be created without a "mnt-by:" attribute. * Any un-maintained person, role or domain object cannot be modified without adding a "mnt-by:" attribute. * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. In this stage the acknowledgement message may include these warnings: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Stage 2 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. * Any NEW reference to an un-maintained person object or to a mntner which has such references will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these warnings and errors: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] ***ERROR: New reference to un-maintained person object [DW-RIPE] ***ERROR: New reference to un-maintained person object [DW-RIPE] in mntner [AARDVARK-MNT] Stage 3 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these errors: ***ERROR: Un-maintained person object referenced [DW-RIPE] ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Statistics ---------- While not a very statistically valid survey, we looked at a few days just after the RIPE meeting to see how many new person objects were created with and without mntner objects. We also queried the new objects some time after creation to allow for a "mnt-by:" to be added later. We also noted how many unique person objects were referenced in any objects in update messages with and without mntner objects. AUTO- references were ignored in both creations and updates, and multiple instances of the same person object being referenced many times were counted as one. -------------------------------------------------------- | Date |Created |Created |Referenced |Referenced | | |with |without |with |without | |--------------------------------------------------------| | 20070515 | 156 | 89 | 925 | 726 | | 20070516 | 111 | 67 | 1022 | 486 | | 20070517 | 85 | 48 | 476 | 185 | | 20070518 | 82 | 18 | 679 | 445 | --------------------------------------------------------

4 5

proposal to maintain all objects
by Denis W 05 Jul '07

05 Jul '07

Hi Wilfried There have been no comments against this proposal and a few in favour of the move. Can the RIPE NCC regard this as a consensus now to implement Stage 1 of the proposal? We will seek further consensus later for the other stages. regards Denis Walker RIPE NCC --------------------------------- New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

1 0

New test server for "IRT by default" behaviour
by Katie Petrusha 04 Jul '07

04 Jul '07

Dear Colleagues, On 1 August 2007, the RIPE NCC will update the RIPE Database server so that IP queries return IRT objects by default. Details of this change are available here: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00113.html To help ensure a smooth transition, we have set up a test server, which can be accessed at: test-whois-default-irt.ripe.net port 43043 This server runs the updated RIPE Database software, and contains data identical to the RIPE Database. You may use this server to test your tools and queries against the new default behaviour. For command line parameters, use "-h test-whois-default-irt.ripe.net -p 43043 <your_query>". The test server will be decomissioned on 1 August 2007. If you have any questions, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards, -- Katie Petrusha Database Department RIPE NCC

3 5

Draft Minutes from Tallin RIPE meeting
by Nigel Titley 29 Jun '07

29 Jun '07

Gentlefolk, I've been very remiss in not posting these minutes before, but the extra time has allowed Chris (of the RIPE NCC) and me to give them an extra burnishing. So, don your sunglasses, and view these excellent minutes. Comments welcome Nigel This email and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the sender of this email by sending a return email to the address above and then delete the e-mail and your response from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Any views or opinions presented are solely those of the author. Any statements made, or intentions expressed in this communication may not necessarily reflect the view of Easynet. No content herein will bind Easynet or any associated company unless confirmed by the execution of a formal contract by Easynet. Any figures or amounts given in this email are quotations only and are subject to change. Although Easynet routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Easynet makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). Easynet Limited a company incorporated and existing under the laws of England and Wales, with company number 2954343 and having its registered office at 44-46 Whitfield Street London, W1T 2RJ.

1 0

IPv6 access to the RIPE Database server is restored
by Katie Petrusha 29 Jun '07

29 Jun '07

[ Apologies for duplicate mails ] Dear Colleagues, IPv6 access to the RIPE Database server has now been restored. The server was unable to respond to queries over IPv6 from 11:12 (UTC), 29 June 2007. Details of this incident are available at: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00118.html We apologise for any inconvenience. If you have any questions or concerns about this, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha Database Department RIPE NCC

1 0