- db-wg - mailman.ripe.net

Deployment of New RIPE Database Web Forms
by matisov＠rascom.ru 10 Aug '11

10 Aug '11

Hello. Possible the new form is better then old and you did do it to give the some new features that were absent in the old. But Before I could copy/past the url of search result and in this string was my request and all keys. Now it's not possible. Before I saw all keys in one look on page. Now I must open your several bookmarks (4) and check I put or not the tick in some check-boxes. It's not very well. Sincerely, Ivan Matisov, Russia, S.-Peterburg, Rascom, +7(812)303-91-70, +7(964)342-36-61, +7(495)956-00-80, fax+7(812)303-91-71

2 1

Deployment of New RIPE Database Web Forms
by Denis Walker 10 Aug '11

10 Aug '11

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC Database Group are pleased to inform you that, after a successful trial period, the new and improved set of web forms for accessing the RIPE Database is now fully in production. The old Query CGI is no longer available. Details of the new services are contained in the recent announcement to the Database Working Group: http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00170.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Questions about network routing
by Zygimantas Surgailis 08 Aug '11

08 Aug '11

Hello, Hope someone can help me. For few months now I've noticed the increased responce time from some of my servers in German datacenters (Lithuania -> Germany) from one Internet provider (this problem doesnt occur when using other providers). Also, the problem occurs only with servers collocated in Hetzner DC. For example traffic to hetzner.de goes through Russia: Tracing route to hetzner.de [213.133.107.227] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms DD-WRT [192.168.1.1] 2 <1 ms <1 ms <1 ms XXXXX.meganet.lt [XXXXXX] 3 <1 ms <1 ms <1 ms 88.223.0.254 4 1 ms 1 ms 2 ms 88.223.0.157 5 <1 ms <1 ms <1 ms 80.232.131.233 6 5 ms 5 ms 4 ms 87.110.223.237 7 6 ms 7 ms 7 ms 195.122.0.133 8 7 ms 7 ms 7 ms 195.122.0.121 9 21 ms 21 ms 21 ms 92.50.199.29 10 98 ms 111 ms 98 ms xe-1-0-0.frkt-ar2.intl.ip.rostelecom.ru [87.226.133.110] 11 76 ms 76 ms 76 ms decix2-gw.hetzner.de [80.81.193.164] 12 83 ms 84 ms 84 ms hos-bb1.juniper2.fs.hetzner.de [213.239.240.243] 13 81 ms 82 ms 81 ms hos-tr3.ms-ex3k1.rz11.hetzner.de [213.239.236.99] 14 81 ms 80 ms 80 ms www.hetzner.de [213.133.107.227] Trace complete. But traffic to e-shelter.de goes directly to Germany: Tracing route to e-shelter.de [91.208.160.80] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms DD-WRT [192.168.1.1] 2 <1 ms <1 ms <1 ms XXXXXXX.meganet.lt [XXXXX] 3 <1 ms <1 ms <1 ms 88.223.0.254 4 * 1 ms 1 ms 88.223.0.157 5 <1 ms <1 ms <1 ms 80.232.131.233 6 5 ms 5 ms 5 ms 87.110.223.78 7 13 ms 13 ms 13 ms xe-0-2-0-301.stk30.ip4.tinet.net [77.67.66.133] 8 78 ms 44 ms 44 ms xe-0-0-0.fra60.ip4.tinet.net [89.149.185.105] 9 46 ms 46 ms 46 ms ge-0-1-0.pr1.k90.fra.de.eurotransit.net [213.200.86.50] 10 39 ms 39 ms 39 ms adacor.demarc.eurotransit.net [82.96.89.182] 11 39 ms 39 ms 39 ms 91-208-160-80.static.ip.adacor.net [91.208.160.80] 12 45 ms 40 ms 39 ms 91-208-160-80.static.ip.adacor.net [91.208.160.80] Trace complete. I've contacted Latvian telecom ant here is their answer: "Path via Rpstelecom is shortest by AS-Path lenght. Router: az8-crs Command: show bgp 213.133.107.227 Mon Jul 25 09:06:29.824 EEST BGP routing table entry for 213.133.96.0/19 Versions: Process bRIB/RIB SendTblVer Speaker 132081071 132081071 Last Modified: Jul 5 00:42:25.785 for 2w6d Paths: (5 available, best #3) Advertised to update-groups (with more than one peer): 0.5 0.14 0.17 Advertised to peers (in unique update groups): 195.122.0.5 Path #1: Received by speaker 0 Not advertised to any peer 3216 13030 24940, (aggregated by 24940 213.133.96.7) 62.231.5.217 from 62.231.5.217 (194.67.0.95) Origin IGP, localpref 90, weight 40, valid, external, group-best Received Path ID 0, Local Path ID 0, version 0 Community: 12578:100 12578:3216 Path #2: Received by speaker 0 Not advertised to any peer 3257 13030 24940, (aggregated by 24940 213.133.96.7) 77.67.67.89 from 77.67.67.89 (213.200.87.15) Origin IGP, metric 170, localpref 100, weight 40, valid, external, group-best Received Path ID 0, Local Path ID 0, version 0 Community: 12578:100 12578:3257 Path #3: Received by speaker 0 Advertised to update-groups (with more than one peer): 0.5 0.14 0.17 Advertised to peers (in unique update groups): 195.122.0.5 12389 24940, (aggregated by 24940 213.133.96.10) 92.50.199.29 from 92.50.199.29 (87.226.134.132) Origin IGP, localpref 110, weight 40, valid, external, best, group-best Received Path ID 0, Local Path ID 1, version 132081071 Community: 12578:300 12578:12389 24940:24940 Path #4: Received by speaker 0 Not advertised to any peer 3249 13030 24940, (aggregated by 24940 213.133.96.7) 195.250.170.49 from 195.250.170.49 (84.50.255.90) Origin IGP, localpref 100, weight 40, valid, external, group-best Received Path ID 0, Local Path ID 0, version 0 Community: 12578:100 12578:3249 Path #5: Received by speaker 0 Not advertised to any peer 3320 3320 3320 24940 24940, (aggregated by 24940 213.133.96.10) 217.243.219.117 from 217.243.219.117 (194.25.5.230) Origin IGP, localpref 100, weight 40, valid, external, group-best Received Path ID 0, Local Path ID 0, version 0 Community: 12578:100 12578:3320 My knowledge is limited, so I'm not sure what should I do next, whom should I contact? Thank You for any help in advance.

3 2

Deployment of New RIPE Database Web Forms
by Denis Walker 04 Aug '11

04 Aug '11

Dear Colleagues The Database Group is pleased to announce the deployment of a new and improved set of web forms for accessing the RIPE Database. These forms allow users to: - Query the RIPE and TEST Databases - Query a set of global Internet resource databases, excluding personal data - Perform a Full text search on the contents of the RIPE Database, excluding personal data - Find Abuse contacts for an Internet resource The new forms are available now at: https://apps.db.ripe.net/search/query.html https://apps.db.ripe.net/search/full-text.html https://apps.db.ripe.net/search/abuse-finder.html The current Query CGI and text search (using Glimpse) were some of the first tools the Database Group wrote for accessing Version 3 of the RIPE Database. These are now almost ten years old. The new forms use up-to-date technology and makes use of the RIPE Database API. The Query form queries the RIPE and TEST Databases providing the same usable features as the old advanced Query CGI. Alternatively it can be used to query the Global Resource Service databases (GRS). The Full text search allows searches over the plain text content of RIPE Database objects, without regard for any relationships. We re-index the text of RIPE Database objects every night. The indexed data is taken from the RIPE-GRS source database, and includes all the operational data but none of the personal data. The Abuse Finder accepts an Internet resource identifier and returns any abuse details found for that resource. This includes "abuse-mailbox:" email addresses, IRT objects and pointers to related objects that include a "remarks:" attribute that contains text that 'looks like' possible abuse contacts. The global Internet resource databases are a set of databases covering the operational resource data from the RIRs and some major routing registries. This Global Resource Service is currently in beta release. All these forms have been available for a while on RIPE Labs. They are now all available as production services. The RIPE Database Search form on the home page of the ripe.net website, will still be linked to the old Query CGI until Wednesday, 10 August. After this date all web queries will use the new form. If you have any issues or find any bugs in the new web forms, please report them to ripe-dbm(a)ripe.net. We will assess any reports quickly and report back with an estimate of time for fixing the problem or an explanation of why it works this way. Some issues may be added to a feature request list and processed after any urgent bug fixes. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Website/Link in ERROR:201 whois output outdated?
by Sascha Lenz 03 Aug '11

03 Aug '11

Hi, i just realized that at least one of the URLs/links the RIPE-db software hands out seems to be outdated (since the RIPE website redesign?) Someone asked me about an error reply he received while trying to query the db and he found this in an ERROR:201 response : % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. % Please see http://www.ripe.net/db/err201.html <---- % for more information. ...which is 404 Just a heads up. Probably there are more outdated links, we/the NCC might want to check that. I can't reproduce this since i have no blocked IP myself (that i know of), so there is a chance the other person is doing something wrong or got a weird whois client and this is not a problem in the database texts. . o O(and if i'm a total dork than those responses are hardcoded in the client) (P.S.: We're not sure why his IP(v6) address is blocked, but that's a different story) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

1 0

Re: [db-wg] Analysis of MNTNER Authentication
by Denis Walker 28 Jul '11

28 Jul '11

Hi Peter We looked a little deeper into this. We noticed there are only 50 MNTNER objects in the database that do NOT have a password. They use a combination of PGP and/or X.509 only. So we looked at where these MNTNERs are used. There are probably many ways to look at this. The one we chose is how allocated address space is managed by LIRs. So we looked at the "mnt-lower:" on the allocation INETNUM objects. Some of these 50 MNTNERs are used in this way. The "mnt-lower:" allows assignments to be created. So this can be seen as a measure of control over the assigned address space. We calculated the cumulative size of the allocation blocks where one of these 50 MNTNERs is used as the "mnt-lower:" as a percentage of the total allocated address space. Cumulative total of allocations 4722688 using one of these 50 MNTNERS Total allocated address space 555648000 Percentage of address space 0.85% controlled by PGP/X.509 only (without any passwords) For the other 99.15% of address space, there may be a PGP or X.509 credential in the MNTNER object, but in addition to a password. Regards Denis Walker Business Analyst RIPE NCC Database Group On 21/06/11:26 7:14 PM, Peter Koch wrote: > Denis, > > thanks a lot for producing the numbers and information. > >> The next step was to look into the referenced MNTNER objects to see how >> many used password, PGP or X.509, and in what combination and numbers. >> >> MNTNER with one auth containing a password = 27,434 85% >> MNTNER with only password = 27,796 86% >> MNTNER with one auth containing a PGP = 952 3% >> MNTNER with only PGP = 1,507 5% >> MNTNER with one auth containing an X.509 = 16 <1% >> MNTNER with only X.509 = 21 <1% >> MNTNER with password plus either PGP or X.509 = 3,023 9% >> MNTNER with PGP plus X.509 (no password) = 50 <1% >> MNTNER with one password plus multiple PGP = 357 1% >> MNTNER with one PGP plus multiple password = 59 <1% > > in addition to what Shane suggested (which methods are actually _used_), I'd > be interested to learn how large of a percentage of the address space (as opposed to > the number of objects) is covered by "password" authentication. This is > to avoid artefacts by passwords being used for small chunks and PGP/X.509 > for the larger ones - or vice versa. > > Thanks, > Peter >

1 0

New Syncupdates service
by Denis Walker 21 Jul '11

21 Jul '11

Dear Colleagues, As part of the RIPE NCC Database Group's ongoing efforts to improve our infrastructure, we are pleased to announce the launch of a completely re-written Syncupdates service. This new Syncupdates is easier to maintain and improve than the old version, which was written almost ten years ago. The Syncupdates interface for users of the service is unchanged, so from a user viewpoint, nothing has changed. Any software or scripts written to access Syncupdates will continue to work without any need for modifications. A more detailed article will follow shortly on RIPE Labs with additional technical details about the new Webupdates and Syncupdates services. If you do have any problems with the new Syncupdates please contact <ripe-dbm(a)ripe.net>. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

DOMAIN attributes review
by Denis Walker 14 Jul '11

14 Jul '11

[Apologies for duplicate emails.] Dear Colleagues, At the RIPE 62 Meeting we were asked to consider the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data there is no longer any use case for the "mnt-lower:" attribute. Other attributes that are considered to be used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed below show how many of the above attributes have been added to reverse delegations and ENUMs. The RIPE NCC would like to ask the community if anyone sees any justification for the use of these attributes in reverse delegations or ENUMs. If there is no justification, all four of these attributes can be removed from all DOMAIN objects when the last two TLD operators move their data out of the RIPE Database. This is anticipated to occur by the end of 2011. To keep any discussion focussed please send any comments or feedback to the DNS Working Group Mailing list. Regards Denis Walker Business Analyst RIPE NCC Database Group Statistics ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2219 unique maintainers = 140 "mnt-lower:" = 46485 unique maintainers = 4208

1 0

RIPE Database Query API on RIPE Labs
by Paul Palse 22 Mar '10

22 Mar '10

Dear colleagues, We implemented a RIPE Database Query API in form of a RESTful Web Service. See a detailed description on RIPE Labs: http://labs.ripe.net/content/ripe-database-api We are curious to find out if this is useful and what additional features you would like to see in the future. Please put your comments in the forum set up for this discussion: http://labs.ripe.net/content/ripe-database-api-0 Regards, Paul Palse -- Database Group Manager at RIPE NCC http://www.ripe.net/info/ncc/contact.html

1 0

Call for agenda items, DB-WG Meeting during RIPE60, Prague, CZ
by Wilfried Woeber, UniVie/ACOnet 21 Mar '10

21 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear DB-WG folks, planning activities for the next RIPE Meeting - RIPE60 in Praha, CZ - have already started, thus this call for agenda items. Please submit (to the WG list!) your item requests and|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 28th of March.) Please note that the DataBase-WG meeting is scheduled for *Thursday* (in the morning, starting at 09:00). The overall RIPE 60 meeting outline is already available at http://www.ripe.net/ripe/meetings/ripe-60/meeting-plan.html Looking forward to a successful meeting and seeing you in Prague, Wilfried. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iQCVAwUBS6Xby9/RXX7wrLNpAQI3NQP/XBLWwyzLo5PfnLSaJk2gfb3YKW+zirb5 7UcNlFmWuxriLtk57YFIbvjl6mrbAA+9dtfm6l8Lt7cZWDdyljDBKL9o33+p+boQ kPyLpDSLoPRIcN6/5cQCxZbHhYd8HTmfvFu4MUGPmRTbQtLJQxvqTsxvxzeiwNI1 um7KUVrwNcA= =cyqz -----END PGP SIGNATURE-----

1 0

Clean-up of backlog of unreferenced personal data completed
by Denis Walker 08 Mar '10

08 Mar '10

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC has now completed the clean-up of the backlog of unreferenced PERSON and ROLE objects in the RIPE Database. The results of this process can be seen on the RIPE Database inconsistency graph for Unreferenced Person/Role Objects: http://www.ripe.net/projects/dbconstat/cons-unrefpero.html Since this process began, almost half a million objects have been deleted. Our Customer Services Department received only a handful of tickets related to these object deletions. The clean-up script will continue to run and keep the RIPE Database clear of unreferenced PERSON and ROLE objects. For details of this process, see: http://www.ripe.net/db/support/unreferenced-personal-data-clean-up.html Users of the RIPE Database should only create these objects containing personal data when there is a need for them. They should not be created until there is an imminent need to reference them. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Ripe DB mirroring
by mfaraji＠aut.ac.ir 08 Mar '10

08 Mar '10

Hi I want to build a database like ripe. But I only want to store information about ip addresses of my country. I downloaded your software. How can I download objects which are related to ip addresses of my country? Thnaks,

2 1

Clean-up of unreferenced personal data in RIPE Database
by Denis Walker 23 Feb '10

23 Feb '10

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC Database Group has restarted the clean-up of unreferenced personal data. This follows the process outlined in the document recently published at: http://www.ripe.net/db/support/unreferenced-personal-data-clean-up.html Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

Mandatory maintainer on PERSON and ROLE objects
by Denis Walker 18 Feb '10

18 Feb '10

[Apologies for duplicate emails] Dear Colleagues, The Data Protection Task Force asked the RIPE NCC to enforce maintaining all data in the RIPE Database. Currently, the "mnt-by:" attribute is optional in PERSON and ROLE objects. The RIPE NCC has now made this attribute mandatory in both these object types in a test environment. We recommend that anyone who uses automated scripts to generate or modify these objects should test their procedures and scripts against the test facilities. The test server has a recent copy of the RIPE Database data. One significant effect of this change is the circular dependency between PERSON and MNTNER objects. For a new user with no data in the RIPE Database, these two objects must be created together. This cannot be done by the normal update methods. There is a new user start-up interface that creates this pair of objects: https://www.db.ripe.net/cgi-bin/new-user-startup.pl This start-up process is described in the new RIPE Database Update Reference Manual: http://www.ripe.net/db/docs.html The test service is available on a test server at the following URL: whois-mandatory-mntby.db.ripe.net Queries to this database instance can be directed to: whois-mandatory-mntby.db.ripe.net:43 Email updates can be sent to<auto-dbm-mandatory-mntby(a)ripe.net>. Synchronous updates are available at: https://syncupdates-mandatory-mntby.db.ripe.net/ Near Real-Time Mirror (NRTM) access is available at: whois-mandatory-mntby.db.ripe.net:4444 Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

New Update Reference Manual
by Denis Walker 18 Feb '10

18 Feb '10

Dear Colleagues, [Apologies for duplicates] An updated version of the RIPE Database Update Reference Manual has just been published. This reflects a number of changes made over the last year. It is available in both PDF and HTML formats at: http://www.ripe.net/db/docs.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Unreferenced personal data cleanup process
by Denis Walker 16 Feb '10

16 Feb '10

[Apologies for duplicates] Dear Colleagues The RIPE NCC was asked at RIPE 59 to explain in more detail the workings of the new clean-up process for unreferenced personal data. This expanded explanation is now available, with examples, at: http://www.ripe.net/db/support/unreferenced-personal-data-clean-up.html Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

country attribute: "ZZ" for unspecified?
by Christian 'wiwi' Wittenhorst 09 Feb '10

09 Feb '10

Dear DB-WG, might there be a consent for introducing "ZZ" as an allowed value for the "country"-attribute for "unspecified"? Reasoning: - ISO 3166-1 [1] specifies "ZZ" as "User-assigned code elements are codes at the disposal of users who need to add further names of countries, territories, or other geographical entities to their in-house application of ISO 3166-1, and the ISO 3166/MA will never use these codes in the updating process of the standard.". - Many current entries do not specify the correct/meaningful value for country. Examples includes: [2a] RIPE-NCC-K-ROOT: NL [2b] TELTEK-1: GB, but: country is really Europe and Middle East [2c] ORG-AFNC1-RIPE: EU, but: country is really somewhere in African Region [2d] IANA-BBLK-RESERVED1: EU, but RFC1918 network [2e] EU-ZZ-163: EU, but: Country is really world wide [2f] LUXLINK-003: DE, but: These IP's are really World-Wide - For automated statistics it would be nice to have a special designation for IPs which do not correspond to a specific location, so that they are easy to filter. - It could be used for (global) anycast services, too. - ARIN & AfriNIC legacy entries could get a "correct" country. - Documentation says: "There are no rules defined for this attribute.", but the attribute is mandatory? Shouldn't we change that? Either make the attribute optional or specify, what it is supposed to contain. - I am dreaming: Wouldn't it be <http://dict.leo.org/ende?lp=ende&p=5tY9AA&search=desirable>desirable to have a designation for "world", too? - We already have a least on strange countries "EU", which does not seem to be part of ISO 3166-1... I'd like to hear your opinion... Best regards, Christian [1] <http://en.wikipedia.org/wiki/ISO_3166-1> [2a] <http://www.db.ripe.net/whois?searchtext=193.0.14.129&object_type=inetnum> [2b] <http://www.db.ripe.net/whois?searchtext=193.9.152.0&object_type=inetnum> [2c] <http://www.db.ripe.net/whois?searchtext=193.189.128.0&object_type=inetnum> [2d] <http://www.db.ripe.net/whois?searchtext=172.16.0.0&object_type=inetnum> [2e] <http://www.db.ripe.net/whois?searchtext=163.0.0.0&object_type=inetnum> [2f] <http://www.db.ripe.net/whois?searchtext=91.142.59.0&object_type=inetnum>

6 8

[Fwd: Уважаемый Mr.Sergiy Viktorovich Shabatura (BUDREMYER2 - NET) !]
by Max Tulyev 30 Jan '09

30 Jan '09

Hi all, here is a sample of RIPE DB based SPAM. The funniest thing is address it was received is support(a)netassist.kiev.ua is listed only as changed: attribute at this net's (BUDREMYER2-NET) mntner! What is the data leak? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

Уважаемый Mr.Sergiy Viktorovich Shabatura (BUDREMYER2 - NET) !
by Gabriella KOVACS 30 Jan '09

30 Jan '09

Уважаемый Mr.Sergiy Viktorovich Shabatura (BUDREMYER2 - NET) ! Мы Intron Electronics Hungary Ltd. Paботаем с Интернет провайдерами и по етому поводу мы нашли Вас, чтобы найти с Вами общий путь. Ознакомительный лист про нашу фирму мы прикрипили к письме. Зарегистрируйтесь на нашом сайте и Вы найдёте много интересных информаций для Вашей фирме. Спасибо! Всего Доброго! -- Best Regards /Udvozlettel: Gabriella Kovacs (Nemzetkozi Kapcsolattarto - International Contact Person) INTRON Electronics Hungary Kft. (INTRON Electronics Hungary Ltd.) Web: http://www.intron.hu Mail: kovacsg(a)intron.hu Tel.: +36/1/422-1755 Fax: +36/1/422-1756 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. !DSPAM:49828b54265012543113083!

1 0

Deletion of unreferenced PERSON and ROLE objects
by Denis Walker 20 Jan '09

20 Jan '09

Dear Colleagues, The RIPE NCC will start to delete unreferenced PERSON and ROLE objects from the RIPE Database on Monday, 26 January 2009. Any PERSON or ROLE object that remains unreferenced by any operational resource for 21 consecutive days will be marked for deletion. It can be deleted at any time after this period if it remains unreferenced. Unused MNTNER objects that only maintain unreferenced PERSON or ROLE objects will also be marked and then deleted. To minimise any impact on Database Services, a small number of objects will be deleted on a daily basis. The number of daily deletions will gradually increase. It is expected to take several months to remove the backlog of unreferenced objects. After the backlog is removed, all unreferenced PERSON and ROLE objects, and in some cases their MNTNER objects, will be deleted after being unreferenced for 21 consecutive days. For more details, please refer to this support page: http://www.ripe.net/db/support/cleanup-unreferenced-data.html If you have any questions about this, please contact <ripe-dbm(a)ripe.net>. Regards, Denis Walker Business Analyst RIPE NCC

1 0

Maintenance Announcement - 22/01/2009
by Ben O'Hara 19 Jan '09

19 Jan '09

[Apologies for duplicate mails] Dear Colleagues, Between 17:00 and 18:00 (UTC) on Thursday 22 Jan 2009, the RIPE NCC will carry out planned maintenance work on our network infrastructure. During this period all RIPE NCC services will suffer intermittent interruptions We apologise for any inconvenience that this may cause. Regards Ben -- Ben O'Hara RIPE Network Coordination Center Systems Engineer Singel 258, Amsterdam, NL http://www.ripe.net +31 20 535 4444 PGP Fingerprint: 080A 52FF BF0A A7FB F176 E7DB 513D 9A3D E968 7DBC

1 0

Outage report for the RIPE Database services
by Denis Walker 24 Nov '08

24 Nov '08

[ Apologies for duplicate mails ] Dear colleagues, >From approximately 07:30 (UTC) to 18:30 (UTC) on Saturday, 22 November 2008, the RIPE Database web based services were not available. This was due to the scheduled maintenance of our central filer system. During this period it was not possible to connect to the syncupdates or webupdates services or use the query web form or other web based forms. Email updates were also delayed. All the messages received by auto-dbm(a)ripe.net were stored on our mail server. All the saved update messages have been processed. If you sent an email update to the RIPE Database service during this period, you will have already received an acknowledgement message. There is no need to re-send any update messages. We apologise for any inconvenience that this may have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

ANNOUNCEMENT: RIPE NCC Training Courses
by Training 20 Nov '08

20 Nov '08

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The DNS for LIRs Training Course This course teaches LIRs about the RIPE NCC's DNS-related services. A course outline is available at: http://www.ripe.net/training/dns/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

ANNOUNCEMENT: RIPE NCC Training Courses
by Training 30 Oct '08

30 Oct '08

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The DNS for LIRs Training Course This course teaches LIRs about the RIPE NCC's DNS-related services. A course outline is available at: http://www.ripe.net/training/dns/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

2 2

Re: Draft minutes from RIPE 56
by Malcolm Hutty 30 Oct '08

30 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel, your minutes contain the following note under "Follow-ups": "* Resource Certification Project The point was raised that the CA-TF work was a focus for actions by lawful authority to remove items from the database. Would we want to record all such actions. This is properly the domain of the DP-TF and some progress on similar topics has already been made. [AP56.1 DP-TF] To consider the action to be taken when legal authority requests the removal of data from the database, and in particular whether records of such actions should be recorded. It was noted that 2008-04 will result in more ROA data for the DB using data derived from the certification effort." http://www.ripe.net/ripe/maillists/archives/db-wg/2008/msg00027.html During the WG meeting at RIPE57 I would like to ask for an update (and since the WG clashes with the Cooperation WG I will probably have to do so via a sock-puppet). My interest isn't merely in whether such forced-deletions would be recorded, but also whether they would be announced publicly, whether the affected assignee would be informed, and indeed whether they should be done at all (and if not, what steps the NCC should take in advance to protect itself from facing legally enforceable demands. The reasons why this is an issue are more clearly minuted in the AOB section to the minutes to RIPE55, as follows: "* 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." http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00170.html I believe this is likely to become an important policy issue if certification is a success (meaning, if people start to treat with suspicion routing announcements for address blocks for which the announcer cannot produce a RIPE-NCC-signed certificate). It strikes me that there are four strategies available to the NCC: i) cooperate cheerfully with legal requests to delete objects/revoke certificates; ii) seek to persuade legal authorities to forebear from making such requests voluntarily; iii) locate the database in a jurisdiction where such requests are predicted to be unlikely/rare; iv) reengineer the database so that it is split between competing jurisdictions, such that legal authorities in multiple jurisdictions would need to cooperate in order to compromise the database integrity effectively. The RIPE55 minutes indicate that the NCC is currently pursuing the second strategy. None of these are likely to be risk-free. I can imagine pursuing the fourth strategy would be highly politically controversial. On the other hand, I can imagine an existential political threat were the NCC ever to succumb to a request from a Dutch/European court to revoke an address block allocation (/ certificate) for a non-EU address block. I think the WG should consider carefully whether the current approach is sufficient, and how we should react if it fails. Regards, Malcolm. - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkFxrwACgkQJiK3ugcyKhTVJACgkkWkugFNkbWINAz2/4unFrcN q2oAn0QvFt9X3sGHAW5kki2DZJxZF1Z5 =maMo -----END PGP SIGNATURE-----

1 1