- db-wg - mailman.ripe.net

auto-dbm?
by Max Tulyev 26 Apr '07

26 Apr '07

Hi! I sent a number of letters to auto-dbm(a)ripe.net yesterday and today, all of them was accepted by RIPE mail server, but it seems all of them went to /dev/null without any actions and replies. My friends confirm this too. When DB updates will be fixed? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

4 4

[Fwd: [db-wg] auto-dbm?]
by Wilfried Woeber, UniVie/ACOnet 26 Apr '07

26 Apr '07

I guess this rather needs to go to ripe-dbm and (maybe) ops than to DB-WG list.... Wilfried. -------- Original Message -------- Subject: [db-wg] auto-dbm? Date: Thu, 26 Apr 2007 12:08:50 +0300 From: Max Tulyev <president(a)ukraine.su> To: Database WG <db-wg(a)ripe.net> Hi! I sent a number of letters to auto-dbm(a)ripe.net yesterday and today, all of them was accepted by RIPE mail server, but it seems all of them went to /dev/null without any actions and replies. My friends confirm this too. When DB updates will be fixed? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

Cleanup of unreferenced person objects
by Denis Walker 23 Apr '07

23 Apr '07

Hi There has been some useful feedback already on this proposal. Perhaps I need to clarify some points and suggest some changes to the proposal. We have always wanted to keep the database as clean as possible. So whilst half a million extra person objects has no effect on the operation, we prefer them not to be there if they are serving no useful purpose. We have also been looking more closely at Data Protection issues recently. We have a number of points to discus with the Data Protection Task Force. But the bottom line is, we have to define the purpose(s) of the RIPE Database. We are only allowed to keep personal data in the database if it fits the defined purpose. Although we are only at the stage of drafting these definitions, it is difficult to see how unreferenced person objects could fit any definition that we finally agree on. As for e-mails, I have discussed the numbers with our IT operations guys. They are confident we can handle the worst case scenario with our mail servers. So I suggest we process the deletions with the normal notification procedure where e-mails are sent to any "notify:" addresses in the person objects and to the maintainers if maintained. We will use a modified notification text for this purpose. It will refer to a web page that explains why these person objects are being deleted. Regarding the issue of temporary unreferenced person objects. For example when someone is moving to a new company and de-references their person object from the old companies data and intends to reference it with the new companies data. The proposal allows for a (minimum) one month waiting period before deletion. It could be up to two months, depending on when it is de-referenced. If there is a feeling that this needs to be a longer period it can be extended. I hope this addresses the issues so far raised. Regards Denis Walker Database Group RIPE NCC

1 0

Clean up of unreferenced person/role objects
by Denis Walker 23 Apr '07

23 Apr '07

Introduction ------------ According to our database consistency statistics program (dbconstat [1]) we currently have 460,573 unreferenced person/role objects [2]. Some of these may be maintained, but are still unreferenced. Any personal data not referenced by Internet resources do not fit within the purpose of the RIPE Database. They should not be stored in the RIPE Database beyond a reasonable 'work in progress' period. The RIPE NCC has had a mandate to delete these unreferenced person/role objects since RIPE 40: http://www.ripe.net/ripe/wg/db/minutes/ripe-40.html (2001) At RIPE 41, the Database Working Group agreed that "maintained objects will now be removed" and "gave a mandate to the RIPE NCC to continue with the cleanup process." http://www.ripe.net/ripe/wg/db/minutes/ripe-41.html (2002) The cleanup process of 2003 (http://www.ripe.net/db/news/unref-cleanup-200304.html) involved using a script to run periodic cleanups. This script was put in place. However, it failed about 18 months ago. Because of other priorities, we have not had the time to examine this issue again until now. The graph showing the increase in these unreferenced person objects [3] indicates that the cleanup script appeared not to be performing correctly. At the start of 2006, there were about 300,000 unreferenced person/role objects. Since then there has been a steady increase with a large increase of almost 50,000 in February 2007. The graph also shows a slightly higher rate of increases in these objects since February 2007. Because of the high number now of unreferenced person objects, we want to raise the issue with the community again and propose the below procedure to clean them up. Because redundant personal data is a serious data protection issue, we want to take a new approach to this in the future. Once the initial cleanup is in progress, we will create a new proposal for a new, regular cleanup procedure. This will be sent to the Data Protection Task Force [4] and then to the rest of the community. One time bulk cleanup procedure ------------------------------- Month 1 * Select 80,000 unreferenced person/role objects. Month 2 * Check selected person/role objects. * Those still unreferenced: o Delete using normal update process. o 2000 objects per update message. o Run updates overnight (Saturday/Sunday). o One update every 15 minutes. o This should avoid any unnecessary load on the servers. * Select next 80,000 unreferenced person/role objects. Month 3 * Repeat process until complete. Notes ----- This procedure will take about 6 months to clear the current backlog, not including the extra time that may be necessary due to the increases over that period. Because of the high numbers involved, we prefer NOT to send out individual e-mail notifications, either before or after deletion. This is to prevent a high load on our mail servers, especially in the event of a high number of bounced e-mails. This means that there will be no individual announcements to listed e-mail addresses before the deletion and none of the usual update notifications. This also means that even if the objects are maintained, the maintainer will not be notified directly about the deletion of their unreferenced person/role object. We will, however, announce the cleanup to the Working Group mailing lists and as a news item on our web site home page. The worst problem that can occur is that someone will enter a reference to their person/role object just as we delete it. However, as we are only deleting unreferenced person/role objects, the time needed to re-create them is minimal. We suspect that a very large proportion of the unreferenced person/role objects that we will be deleting are abandoned objects that are no longer used. References ---------- [1] dbconstat http://www.ripe.net/projects/dbconstat/index.html [2] current unreferenced person/role objects http://www.ripe.net/projects/dbconstat/html/cons-current.html [3] graph of unreferenced person object increase http://www.ripe.net/projects/dbconstat/cons-unrefpero.html [4] Data Protection Task Force http://www.ripe.net/ripe/tf/dp/index.html

8 12

Updated RIPE Database Manuals
by Denis Walker 17 Apr '07

17 Apr '07

[apologies for duplicates] Dear Colleagues, We are pleased to announce the publication of three updated RIPE Database Documents. ripe-401 RIPE Database Query Reference Manual ripe-402 RIPE Database User Manual: Getting Started DRAFT RIPE Database Update Reference Manual Previously, the Query and Update Reference Manuals were part of ripe-252, The RIPE Database Reference Manual. The content has been thoroughly revised and updated, and we have also improved the wording to make it clearer. The Update Reference Manual also contains a lot of new content, reflecting many of the changes made to the database software over recent years. Because it is so long since this manual has been revised, the list of changes is considerable. It has not been possible to reflect all these changes in the first revision. This is why it is only released as a draft document at this stage. A second revision will take place after the RIPE 54 Meeting. Together, the Query Reference Manual and Update Reference Manual (currently in draft format) will completely obsolete ripe-252. You can find ripe-401 and ripe-402 at: http://www.ripe.net/ripe/docs/database.html The draft of the RIPE Database Update Reference Manual is available at: http://www.ripe.net/ripe/draft-documents/draft_db_manual.pdf Regards Denis Walker Database Group RIPE NCC

1 0

Call for agenda items, DB-WG Meeting during RIPE54, Tallinn, EE
by Wilfried Woeber, UniVie/ACOnet 05 Apr '07

05 Apr '07

Dear DB-WG folks, the RIPE NCC will soon ask us to submit the draft agendas for the WGs. As I'll be out of office till April 18th, I'd like to distribute this Call for Agenda Items even before the Easter Holidays :-) 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 around the 20th of April. The DataBase-WG meeting is scheduled for Friday morning, May 11, 2007. The overall RIPE meeting outline is already available at http://www.ripe.net/ripe/meetings/ripe-54/meeting-plan.html The list of plenary presentations scheduled may eventually be available at [- as of early April this page does not exist yet -] http://www.ripe.net/ripe/meetings/ripe-54/presentations/ See you in Estonia, Wilfried.

1 0

RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007 Postponed
by Mark Guz 05 Apr '07

05 Apr '07

Dear Colleagues, Due to the fact that the RIPE NCC will be closed tomorrow and Monday we have decided to postpone this maintenance until next Wednesday (11/04/07 ). Apologies for the inconvenience this may cause. If you have any questions please send them to ops(a)ripe.net Kind Regards Mark Guz Senior Engineer OPS/IT RIPE NCC Amsterdam

1 0

Concerning the authentication for route object creation
by Hendrik T Voelker 04 Apr '07

04 Apr '07

Dear RIPE, dear Colleagues. I'd like to discuss a topic which most likely has already been discussed several times - only I have not seen that so far. If so, please excuse the 100th time being asked about it and just point me to results of these discussions. Anyway, here we go: According to http://www.ripe.net/info/faq/db/route-creation-IP-space-check.html if it is found that there is no exact matching route object already in existence in the RIPE DB, the less specific route is examined. If one is found deciding for authentication are then contained mnt-routes, mnt-lower or mnt-by fields. What annoys me here is, that holes are completely disregarded, meaning so even if because of defined holes the route object is not authoritative for a network, nonetheless it's authentication data is used. As we have several larger aggregated routes and additional some routes for IP allocations that have a status of "ALLOCATED UNSPECIFIED" we have to update our route objects to include maintainers for other companies so that they become able to maintain PI allocations. If the authentication process would regard holes all we would have to do would be defining a hole once, and not have to change the mnt-routes for a network for every provider change. This might ease the daily business of us all slightly. Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE EMEA Registrar Team Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Gesch�ftsf�hrer: Donald Badoux - Vorsitzender des Aufsichtsrats: Mark Kearns

1 0

RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007
by Mark Guz 03 Apr '07

03 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [apologies for duplicates] Dear Colleagues, On Thursday 05/04/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to the deployment of a new section of dark fibre between two of our PoPs If you have any questions about this, please send an e-mail to: ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Department RIPE NCC http://www.ripe.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEhqgl42z2L2N9gERAofHAKClFauaor8xhKENLD4dp5PSfN9MFQCfZhCh D1RBdhQbWlox3dtzLzLPvLE= =g9jU -----END PGP SIGNATURE-----

1 0

NOC / Lookinglass Information in the RIPE DB
by Jeroen Massar 29 Mar '07

29 Mar '07

Hi, I am probably approaching this from the wrong way, in that case point me at the right way so that I can do it in the correct way. It needs discussion first anyway, so here we go: RIPE currently has a couple of projects going on which help in solving network connectivity issues, amongst those of course the really nice RIS tool (I love BGPPlay btw :) and the debogon projects. The latter project can be used by a network admin to check if that, to be debogonized network, is reachable. This does not help with network problems that might occur at other places. Now what if we could have an object in the RIPE registry that would explain us where to find Looking Glasses that are applicable for a prefix? I am thinking of something in the area of the following: route: 192.0.2.0/24 descr: Documentation Network origin: AS23456 lookingglass: http://noc.as23456.net/lg/ reachable: icmp:192.0.2.1 reachable: http://192.0.2.1 mnt-by: RIR-MNT source: RIPE # Filtered One could debate that maybe putting the proposed 'lookingglass' and 'reachable' addresses might be better suited in the ASN object. Another option to store this data would be to create a new 'noc' object and to have the details in there. The above information, when available, could then easily allow operators who have a problem with a certain prefix to find the lookingglass which allows them to look at the problem from the remote angle, without having to contact that NOC. This will give people with network problems a better insight, which allows for better reporting of the issue, and thus hopefully faster resolution of issues. There are indeed resources (eg www.traceroute.org) which list these items, but it is much more scalable and reliable to have it in the RIPE registry. What do folks think about this? Useless? Useful? Nonsense? ??? :) Greets, Jeroen

4 4

whois-server friendly client programming
by Henning Brauer 02 Mar '07

02 Mar '07

Hi, I am writing a tool to generate OpenBGPD filters from the policy specification in aut-num objects. Naturally, this involves sending a lot of queries to the whois servers: -one for the aut-num in question -one for every as-set given in the policy -one for every member of these as-sets, and recursively for their members, until we're down to an all-aut-num list -for each aut-num, a query for the routes it exports (-i origin <AS>) I do have extensive caching in place, all responses are beeing cached (or rather, the parse result), so no query is ever sent twice. nontheless, a lot of queries remain. right now, I have whois.ripe.net hardwired, of course this is going to change before the tool is released. I am using "-r -a -T <objtype> <object>" for aut-num and as-set, and "-r -a -T <objtype> -i origin <as>" for route objects. Questions: can I make life easier for the whois servers by using another set of query options? what is a good default whois server? whois.ripe.net? whois.radb.net? of course, I run into the penalty delays the whois server imposes because of the amount of queries I send. How do I deal with that? do nothing, just accept the delay (that's how it is now)? is it possible (and feasable!) to mirror the entire IRR? is this documented somewhere? I'd happily point to that documentation and recommend running a local mirror in the manpage if that is feasable. the forced delays also make development pretty painful ;( Thanks & Greetz Henning Brauer -- Henning Brauer, hb(a)bsws.de, henning(a)openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

4 4

Deprecation of CRYPT-PW authentication method from the RIPE Database
by Agoston Horvath 21 Feb '07

21 Feb '07

[Apologies for duplicate mails] Dear Colleagues, The CRYPT-PW deprecation project ends today, Wednesday, 21 February 2007. From today, the following changes will apply: * CRYPT-PW passwords will be disabled in the syntax * CRYPT-PW passwords will be disabled in authorisation * CRYPT-PW passwords will be removed from existing maintainer objects If a maintainer object contained CRYPT-PW passwords only, the passwords were replaced with a randomly generated MD5-PW password. If a maintainer object used an authentication method that was not CRYPT-PW, the CRYPT-PW auth: lines have been removed. To retrieve the removed CRYPT-PW passwords, please visit: https://www.ripe.net/cgi-bin/crypt2md5.cgi The RIPE NCC has recently upgraded its mail servers to support TLS/SSL. If you are updating the RIPE Database by email, please use an SMTP server that supports TLS/SSL. This will protect your data where possible. The use of an SMTP server that supports TLS/SSL is particularly important if you use cleartext password (MD5-PW) for authentication instead of PGP or X509. More information is available at: http://ripe.net/news/tls.html Notification e-mails will be sent today to over 5100 e-mail addresses. A total of 2337 objects had CRYPT-PW authentication only. Another 179 objects had other authentication methods in addition to CRYPT-PW. More information about the project is available at: http://www.ripe.net/db/support/security/crypt-pw_deprecation/ If you have any questions, contact: ripe-dbm(a)ripe.net. Regards, Agoston Horvath Database Group RIPE NCC

1 0

RIPE NCC Planned Maintenance, February/March 2007
by RIPE NCC 19 Feb '07

19 Feb '07

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC will perform maintenance work that will affect a number of servers. The maintenance work will take place on: Tuesday, 20 February 2007 between 18:00 and 20:00 UTC Thursday, 22 February 2007 between 18:00 and 20:00 UTC Tuesday, 27 February 2007 between 18:00 and 20:00 UTC During this maintenance, individual servers may experience short outages. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to ops(a)ripe.net. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC

1 0

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

12 Feb '07

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Thursday 5 April 2007 Time: 09:00 - 17:00 Location: Manama, Bahrain Hosted by: 2Connect:http://www.2connectbahrain.com/ AND Date: Thursday 26 April 2007 Time: 09:00 - 17:00 Location: Budapest, Hungary AND Date: Friday 4 May 2007 Time: 09:00 - 17:00 Location: Amsterdam, Netherlands AND Date: Friday 25 May 2007 Time: 09:00 - 17:00 Location: Moscow, Russian Federation AND Date: Thursday 7 June 2007 Time: 09:00 - 17:00 Location: London, United Kingdom ND Date: Friday 29 June 2007 Time: 09:00 - 17:00 Location: Rome, Italy 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

Transfer of ERX resources from RIPE NCC to AfriNIC
by Andrei Robachevsky 12 Feb '07

12 Feb '07

[Apologies for duplicate e-mails] Dear colleagues, On Wednesday 14 February 2007, the RIPE NCC will transfer management of several Early Registration PI address blocks and Autonomous System Numbers to AfriNIC. A list of the resources being transferred is available at: http://www.ripe.net/projects/erx/transferred.html You can find more information about AfriNIC at: http://www.afrinic.net For more information on the ERX project, see: http://www.ripe.net/projects/erx/index.html Regards, Andrei Robachevsky, Chief Technical Officer RIPE NCC

1 0

New mirrored database: ARIN Routing Registry
by Katie Petrusha 12 Feb '07

12 Feb '07

[Apologies for duplicate mails] Dear Colleagues, We have added the ARIN-RR database to our list of mirrored databases. The ARIN-RR database contains Routing Registry (RR) data from rr.arin.net. A list of all mirrored databases is available at: http://www.ripe.net/db/mirrored.html If you have any questions about this, please contact: ripe-dbm(a)ripe.net. Regards, -- Katie Petrusha Database Group RIPE NCC

1 0

Multiple export statements per peer-as in aut-num objects
by Jan Wagner 12 Feb '07

12 Feb '07

Hi there, is the following supported? export: to AS54321 announce AS12345 export: to AS54321 action aspath.prepend (AS12345, AS12345); announce AS12345:AS-BACKUPDOWN We try to use rtconfig to generate filter lists, but only the first export line is used. Is this a bug or are multiple export lines not supported by rpsl? Thank and with kind regards, Jan. -- Never write mail to <waja(a)spamfalle.info>, you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------

1 0

SSL/TLS mail
by Max Tulyev 07 Feb '07

07 Feb '07

Hi! Is there any news about implementing SSL/TLS on DB mail servers? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 2

Tonight's RIPE NCC Maintenance Rescheduled for 13 February
by Mark Guz 06 Feb '07

06 Feb '07

[Apologies for duplicate e-mails] Dear Colleagues, We have cancelled plans to carry out maintenance work on our core network infrastructure this evening. This means that RIPE NCC services will be available as usual. We will carry out this maintenance work on Tuesday, 13 February between 21:00 and 23:00 (UTC). During this time, many of our services will be unavailable. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to <ops(a)ripe.net>. Regards, Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445

1 0

Re: IP Address Management Tool
by Sjoerd Krol 30 Jan '07

30 Jan '07

We're using Northstar overhere : http://www.brownkid.net/NorthStar/ Looks simple but it's usefull enough for us... The site your referring to seems indeed to have become a mp3 downloadsite?? Cheers, Sjoerd Krol Ram Mobile Data Netherlands <berthy.vanderjag t(a)kpn.com> Sent by: To db-help-admin@rip <ripe-dbm(a)ripe.net>, e.net <linux2play(a)gmail.com> cc <ripe-list(a)ripe.net>, 01/30/2007 09:44 <db-help(a)ripe.net>, AM <db-wg(a)ripe.net> Subject IP Address Management Tool Hullo All, This is my first call to the forum. I noticed on the RIPE site earlier discussions on a free ipdb tool which was supposed to be available through Global Crossing through the URL: http://www.freeipdb.org This URL gives me no joy however, is this all a joke? And has anyone good recommendations for an IP Management tool to handle the stockcontrol, allocations and assignments of Ipv4 and Ipv6 addresses for a telecoms company? We have been having no end of solutions presented to us which each just didn't quite do what promised :( Anybody out there with good experiences with any tool? Kind regards, Berthy van der Jagt KPN The Netherlands

2 1

(no subject)
by Mark Guz 30 Jan '07

30 Jan '07

[Apologies for duplicate e-mails] Dear Colleagues, On Tuesday 6 February, between 21:00 and 23:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to BGP load balancing issues between our NikHef and Telecity peering points. If you have any questions about this, please send an e-mail to: <ops(a)ripe.net>. Regards -- Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445 http://www.ripe.net

1 0

Re: IP Address Management Tool
by Tobias Cremer 30 Jan '07

30 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Berthy, On 29.01.2007 15:04, berthy.vanderjagt(a)kpn.com wrote: > And has anyone good recommendations for an IP Management tool to handle > the stockcontrol, allocations and assignments of Ipv4 and Ipv6 addresses > for a telecoms company? We use an IP address management tool based on the RIPE Whois server software. One of its main advantages is that is synchronises the assignments with e.g. the official RIPE Whois repository, and sure it can handle your mentioned stock control, allocations and assignments. A presentation I hold at ripe-50 can be found here, however we've added some more functions and IPv6 support in meanwhile: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-mon-… An up-to-date introduction will be held at the APRICOT meeting end of February in Bali, I'm sure the slides will be online then as well. If you're interested, I can give you more information off-list. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvxvThC6y11CNwvcRAnyAAJ91hV74BrSourjf+RsiDrIEZ/VCfgCgj47B ubCoikUsSKWiOqQXCXIsPkY= =WXdl -----END PGP SIGNATURE-----

1 0

RIPE NCC Planned Maintenance, February 2007
by RIPE NCC 29 Jan '07

29 Jan '07

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC will perform planned maintenance work that will affect a number of servers. The maintenance work will take place on: Thursday, 1 February 2007 between 21:00 and 23:00 UTC Wednesday, 7 February 2007 between 21:00 and 23:00 UTC During this maintenance, individual servers may experience short outages. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to: ops(a)ripe.net

1 0

Deprecation of CRYPT-PW authentication method from the RIPE Database: Start of Phase 2
by Agoston Horvath 10 Jan '07

10 Jan '07

[Apologies for duplicate mails] Dear Colleagues, Phase 2 of the CRYPT-PW deprecation project will start today, Wednesday, 10 January 2007. During this period the following will apply: * Any modification to a maintainer or IRT object that adds a new CRYPT-PW authentication will be rejected * Any modification to a maintainer or IRT object that attempts to replace a CRYPT-PW with another CRYPT-PW will be rejected * Any object creations that include a CRYPT-PW authentication will be rejected * The RIPE Database will add a warning to the acknowledgement message if CRYPT-PW is used during authentication * The RIPE Database will add a warning to the acknowledgement message if a modified maintainer or IRT object still contains existing CRYPT-PW authentication Notification e-mails will be sent today to over 6300 e-mail addresses, concerning a total of 2778 objects with CRYPT-PW authentication only. Another 252 objects have other authentication methods in addition to CRYPT-PW. 20898 maintainers have no CRYPT-PW password at all. If you receive a separate notification e-mail you will have to change your password authentication method to PGP, X.509 or MD5-PW. To change your password authentication method from CRYPT-PW to MD5-PW, use the CGI at: https://www.ripe.net/cgi-bin/crypt2md5.cgi Phase 1 of the project has been successfully completed. One quarter of all objects containing CRYPT-PW authentication have been modified. Over 85% of these changes were made using the crypt2md5.cgi web form. More information about the project is available at: http://www.ripe.net/db/support/security/crypt-pw_deprecation/ *Key dates* Thursday, 30 November 2006: Notification (Phase 1) Wednesday, 10 January 2007: Reject new CRYPT-PW (Phase 2) Wednesday, 21 February 2007: Remove CRYPT-PW from RIPE Database (Phase 3) If you have any questions, contact: ripe-dbm(a)ripe.net. Regards, Agoston Horvath Database Group RIPE NCC

1 0

inetnum object addition - error
by linux baby 09 Jan '07

09 Jan '07

Thanks for your help. Please help me to add the inetnum object. i have created the following RR1-SAMPLE, RR2-SAMPLE - person objects created SAMPLE-MNT - mntner object created I have the inetnum object input file like below --------------- cat /usr/local/src/nic/ipcheck.input inetnum: 10.11.12.0 - 10.11.12.255 netname: NIC-NETWORK descr: THIS IS TESTING RANGE country: IN admin-c: RR1-SAMPLE tech-c: RR2-SAMPLE status: ASSIGNED PA remarks: This network should never be routed outside an enterprise notify: raja(a)nic.in mnt-by: SAMPLE-MNT mnt-lower: SAMPLE-MNT mnt-routes: SAMPLE-MNT password: redhat123 source: SAMPLE changed: raja(a)nic.in 20070109 ------------ i checked the range available by whois -p 43001 -h knagalin.linux2all.net 10.11.12.0 - 10.11.12.255 [Querying knagalin.linux2all.net] [knagalin.linux2all.net] % This is the NIC Whois server. % Note: this output has been filtered. % Information related to '0.0.0.0 - 255.255.255.255' inetnum: 0.0.0.0 + - + 255.255.255.255 netname: + WHOLE-IPV4 + descr: The Whole IPv4 country: NL remarks: Country is really worldwide + admin-c: RDBM-SAMPLE # admin contact tech-c: RDBM-SAMPLE # tech contact status: ALLOCATED PI mnt-by: TEST-DBM-MNT source: SAMPLE # Filtered I try to add in my whois server database [root@knagalin whoisd]# ./bin/dbupdate -c ./conf/rip.config.sample -f /usr/local/src/nic/ipcheck.input SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [inetnum] 10.11.12.0 - 10.11.12.255 ***Info: Syntax check passed inetnum: 10.11.12.0 - 10.11.12.255 netname: NIC-NETWORK descr: THIS IS TESTING RANGE country: IN admin-c: RR1-SAMPLE tech-c: RR2-SAMPLE status: ASSIGNED PA remarks: This network should never be routed outside an enterprise notify: raja(a)nic.in mnt-by: SAMPLE-MNT mnt-lower: SAMPLE-MNT mnt-routes: SAMPLE-MNT source: SAMPLE changed: raja(a)nic.in 20070109 Please tell me where i am making mistake, Please help me to add the inetnum object in my whoisd server database. Waiting for your reply. regards Karthikeyan.N On 1/9/07, RIPE Database Manager <ripe-dbm(a)ripe.net> wrote: > > Dear Karthikeyan.N > > As I pointed out to you yesterday it will be a good idea to read the > > RIPE Database User Manual: Getting Started > http://www.ripe.net/ripe/docs/db-start.html > > This clearly explains how to create objects in the RIPE Database and how > to > query for them. It was written to help new users to get started. > > The answer to your specific problem below is the '# Filtered' comment on > the "source:" line. The update program will not accept updates with > filtered > query output. > > You may also want to check your database naming as you have used nic-hdls > like AA1-TEST with a source of SAMPLE. Maybe these should both be either > TEST or SAMPLE. > > -- > Regards, > Denis Walker > > RIPE Database Administration > > > On Tue, 9 Jan 2007 10:44:19 +0530, Linux Baby wrote: > * hi, > * Can you give me one example for dbupdate command to > * create/delete/update > * objects using commandline/webinterface. > * > * regards > * Karthikeyan.N >

1 0