- db-wg - mailman.ripe.net

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

Outage Report for RIPE Database Updates
by Agoston Horvath 28 Oct '08

28 Oct '08

[Apologies for duplicate mails] Dear Colleagues, Between approximately 20:05 - 23:14 (UTC) on Monday, 27 October 2008, we experienced an outage in our RIPE Database updates service. During this period, it was not possible to connect to the syncupdates or webupdates services. During the outage, all the messages received by auto-dbm(a)ripe.net were stored on our mail server. If you sent an email update to the RIPE Database during the outage, you will have already received an acknowledgment. There is no need to re-send any update messages. We apologise for any inconvenience that this may have caused. Regards, Agoston Horvath Database Group RIPE NCC

1 0