- db-wg - mailman.ripe.net

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

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

2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)
by Filiz Yilmaz 28 Oct '08

28 Oct '08

PDP Number: 2008-09 ASPLAIN Format for the Registration of 4-byte ASNs Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-09.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 17 November 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

12 14

irt-nfy field
by Andre Koopal 20 Oct '08

20 Oct '08

Hi, After getting some abuse complaints again on the wrong address, I noticed that with a whois without options that the irc-nfy: field is not suppressed. Seems to me that this was an oversight in the implementation of not showing any e-mail addresses except for abuse-mailbox by default. Can this be fixed? Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - European O&T Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands VNET: 711 6990 tel : +31 (0)20 711 6990 fax : +31 (0)20 711 2519 Verizon Business - global capability. personal accountability. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Verizon Nederland B.V. - H.J.E. Wenckebachweg 123, 1096 AM, Amsterdam, the Netherlands - Commercial Register No. 34199467

1 0

Fwd: [routing-wg]Representation of four byte AS numbers.
by Wilfried Woeber, UniVie/ACOnet 19 Oct '08

19 Oct '08

Dear DB-WG partcipants, please have a look at the message below. This issue is expected to appear on our "plate" pretty soon, either in Dubai or during the subsequent RIPE meeting. In particualr I'd suggest you have a look at the URL poinitng to the proposal write-up in the APNIC region, regarding the whois/DB behaviour. Bestregards, Wilfried. -------- Original Message -------- Subject: [routing-wg]Representation of four byte AS numbers. Date: Sun, 19 Oct 2008 10:47:56 +0100 From: Rob Evans <rhe(a)nosc.ja.net> To: routing-wg(a)ripe.net Hi all, At some point in the coming week I expect to see a new policy proposal hit the policy-announce and address-policy mailing lists that we might want to be aware of here. In past working group sessions we've already discussed the benefits and disadvantages of the various methods of representing 32 bit ASNs (i.e. 'asplain,' 'asdot'). There is now an internet-draft recommending asplain (which is just a single 32 bit integer) in last call at the IETF which can be obtained from the following URL: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt A related policy proposal reached consensus at the last APNIC meeting and is now in last call there: http://www.apnic.net/policy/proposals/prop-065-v001.html Whilst we already have a presentation on experiences of using a 32 bit ASN scheduled for the Routing working group session, the policy is being discussed in the Address Policy working group. At the moment it will be presented during the session just before lunch on Tuesday morning. At the same time there will also be a presentation on the proposal for certification of PA resources, which you may also be interested in. All the best, Rob

1 0

Deleting unreferenced PERSON objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, We announced at RIPE 56 that the RIPE NCC would soon start to delete unreferenced PERSON and ROLE objects. This will begin in late November 2008. There are some people involved in the Internet industry who do not directly manage Internet resources but who have PERSON objects in the RIPE Database. If you fall into this category and you believe your PERSON object should not be deleted, you have the option to join the RIPE Database White Pages. This will prevent your PERSON object from being deleted. For further details, please see this web page: http://www.ripe.net/db/support/white-pages-instructions.pdf Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Maintaining DOMAIN objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, The RIPE Data Protection Task Force advised the RIPE NCC that all objects in the RIPE Database should be maintained. Maintaining Routing Policy Specification Language (RPSL) objects in the RIPE Database was optional for PERSON, ROLE and DOMAIN objects. All the DOMAIN objects in the RIPE Database are now maintained and protected. As there may have been a possibility to exploit this data if any advance warning had been made, the RIPE NCC did not publicly announce that it was going to add maintainers to unmaintained DOMAIN objects before doing so. For further details of what was done, please see this web page: http://www.ripe.net/db/support/security/domain/syntax.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

RIPE57 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 16 Oct '08

16 Oct '08

Dear DB-WG folks, Chairpersons, "Meeting"! This is the (very rough) 1st draft of an agenda for the DB-WG at RIPE57 in Dubai, October 2008. For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-57/meeting-plan.html Attention please: this time the DB-WG meeting is again scheduled for th last day of the meeting, *Thursday* at 9 AM in the morning! Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda! This time Nigel Titley will manage the meeting as I can't be in Dubai. Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from RIPE 56 . review of action list B. Data Base Update (Jos I. B., RIPE NCC) C. Follow-Up/Closure of Task-Force on Data Protection Issues (N.N., RIPE NCC) Y. Input from other WGs and TFs . ASN32 . DNS [t.b.c.] Z. AOB ________________________________________________________________________

1 0

Outage report for updates to the RIPE Database
by Denis Walker 13 Oct '08

13 Oct '08

[ Apologies for duplicate mails ] Dear colleagues, >From approximately 19:41 (UTC) to 20:15 (UTC) on Friday, 10 October 2008, some e-mail update messages to the RIPE Database service, auto-dbm(a)ripe.net, were not processed due to a problem with our system. During the same period it was not possible to connect to the syncupdates or webupdates services. All the messages received by auto-dbm(a)ripe.net were stored on our mail server. The problem was resolved on Friday evening. All the saved update messages have been processed. If you sent an e-mail 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

Draft minutes from RIPE 56
by Nigel Titley 10 Oct '08

10 Oct '08

Folks, Looks like I forgot to circulate the minutes from RIPE 56. Please find attached Nigel Minutes of the Database WG RIPE 56 (Berlin) Thursday, 8 May. 16:00-17:30 A. Administrative Matters * Welcome * Select a scribe (Nigel T) * Finalise agenda Agenda accepted * Approval of Minutes from WG session at RIPE 55 Minutes approved. Move from draft status * Review of action list (Nigel T) [AP55.2] To be taken offline All the rest will be dealt with below B. Database Update - Jos I. Boumans, RIPE NCC * See presentation * Actions from previous meetings AP54.3 Mandatory MNT-BY. Code is completed but two issues which means that before can be deployed much more rigorous testing needed to be done. Ongoing AP54.7 rev-srv deprecation. Needs a database schema change. Will be released at the same time as AP54.3. Ongoing AP54.4 White pages. New org-type and will be maintained by WG-Chairs. AP54.6 Clean up unref'ed person objects. Started. 400k remain. Same problem as AP54.3. Start by implementing AP54.4. Monitor object weekly from outside DB and remove if unreferenced for 3 weeks. Ongoing AP55.1 Add mnt-irt to LIRportal. This is not possible at the moment. It has been added to the rewrite schedule for the portal which will take place late this year or early next. Ongoing * Future of RIPE DB DB Team would like to pause and reflect and decide on how the database should change to reflect current requirements. * DB Terms & Conditions Now clearly defined. RIPE NCC can now remove data as required by law. Discharges AP55.3. * Stats Lots of pretty graphs. See presentation. * IRIS Very lightly used. Prototype code. Feature frozen. Suggestion to deprecate. It is suggested that there is much higher use in the domain area. DENIC are intending to release a client and server, but orientated to the domain side. Possibly sometime this year. The RIPE version just proxies to the RIPE database. There is less than 1 query per day. It was agreed that it should be deprecated. * RRCC (Routing registry Consistency Check) Suggestion to integrate with RIS and deprecate as standalone service. Agreed. * Mirroring RR No protocol, so breaks down when syntax changes. Attributes with no equivalents result in data being dropped. Only about 12% of queries are actually valid. 5% of valid queries are for route objects and so this question is being asked of the routing WG too. Proposal is to build a joint referral service. Replies would be in the format of the remote DB (which may be problematic). The point was raised that it is impossible to do CIDR type searches directly on the ARIN database and so the mirroring service is useful. A desire was expressed for a little more data on how frequently sync is lost (1 - 2 times a month) and how quickly it can be recovered (depends on the other registry). Some users of the service raised the point that returning results that are not in RPSL would be a problem. They suggested that this would be a far worse problem than returning stale data. C. Follow-Ups * Task-Force on Data Protection Issues Summary report will be presented tomorrow in the plenary * Contact Data Quality/Requirements Discussion Nothing appropriate for the moment * 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. D. High Avalability SW Update for IRR - Yasuhiro Shirasaki, NTT * Using ripe-whois and our experimental syncronization trial See presentation General enthusiam for the work done. The improvements in speed are partly due to the original code being some 7 years old. This gives further impetus to the RIPE DB team to be allowed time to think and reflect on the database re-write. Y. Input from Other Working Groups and Task Forces None Z. A.O.B None

1 0

Call for agenda items, DB-WG Meeting during RIPE57, Dubai, UAE
by Wilfried Woeber, UniVie/ACOnet 25 Sep '08

25 Sep '08

Dear DB-WG folks, planning activities for the next RIPE Meeting - RIPE57 in Dubai - 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 in about one week from now.) Please note that the DataBase-WG meeting is, again, scheduled for *Thursday* (in the morning) - due to the meeting starting on Sunday. The overall RIPE 57 meeting outline is already available at http://www.ripe.net/ripe/meetings/ripe-57/meeting-plan.html The list of plenary presentations and the session archive may eventually become available at [- this page probably does not exist yet -] http://www.ripe.net/ripe/meetings/ripe-57/presentations/ or at a different URL. Have a successful meeting in Dubai, Wilfried.

1 0

Adequate contact information in the RIPE database must be enforced (was: NCC#2008090071 Unreachable Italian Host)
by Thor Kottelin 03 Sep '08

03 Sep '08

Anonymized extracts from a correspondence between a phish takedown operator and the RIPE NCC: PIRT: "There's a phish on 192.0.2.227. The server is rooted. The address a(a)a.example.net in the IP whois comes back 'host not found'. The ASN address we have, b(a)b.example.net, comes back 'connect timeout'. c(a)c.example.net comes back 'Address rejected'. The webform on the allocee's website (such as it is) doesn't actually do anything.--RIPE can you contact the IP owner and get them to update your database please." RIPE NCC: "Please try contact the Network owners/maintainers. Phone number registered for the maintainer is correct and working." PIRT: "I'm a volunteer and don't have the resources to make international phone calls. Plus I don't speak Italian (I don't write Italian either but there are websites for translation, which is why email is preferable). Doesn't RIPE have the resources to do this? And isn't it in your interest to keep the database accurate? Otherwise what's the point? I have already emailed the d(a)d.example.net address. I have had no reply and the phish is still active." RIPE NCC: "There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity." (End of correspondence extracts.) The issue of false or otherwise inadequate RIPE database entries has been discussed before in various RIPE working groups. It is bizarre that the problems nevertheless continue, year in and year out. Publishing sufficient and up-to-date contact information in the RIPE database should be an absolute prerequisite for holding any kind of RIR-allocated resource. Whenever a deficiency is discovered and reported, the RIPE NCC should efficiently and urgently contact the allocee, requiring a full and immediate correction. If one is not made, the resources should be deregistered. I realize that IP connectivity is not directly contingent on registration, but I also believe that allocees would still want to avoid having their resources bogonized. Should this pressure nevertheless prove insufficient, further sanctions, such as elevated fees, should be available. It is intolerable that important and urgent security-related communications repeatedly fail due to a lack of adequate contact information. -- Thor Kottelin CISM, CISSP fax +358 102 961 064 thor(a)anta.net, PGP 0x327B7345 http://www.anta.net/

4 3

RIPE Database legal documents
by Denis Walker 28 Jul '08

28 Jul '08

Apologies for duplicates] Dear Colleagues, The RIPE Data Protection Task Force (DP TF), working with the RIPE NCC and the company lawyers, has finalised a set of legal documents for the RIPE Database. These documents are: - RIPE Database Terms and Conditions - RIPE Database Acceptable Use Policy - Procedure for the Removal of Personal Contact Details from the RIPE Database They can be seen on the RIPE DP TF web page at this address: http://www.ripe.net/ripe/tf/dp/index.html The documents have been subjected to a final review by the DP TF but they are not yet legally effective. They are now available for review and comments by the wider community. Please let us know if you have any considerations or issues. Please bear in mind that with any documents such as these, the wording can always be changed. However, we would prefer not to make any subjective changes at this stage but only amend anything that is inaccurate. The documents will become legally effective from 1 September 2008 and they will then be available on a new Legal Documents page on the RIPE NCC website. Regards, Denis Walker (on behalf of the RIPE DP TF)

2 1

Subject: White Pages Implementation
by Denis Walker 24 Jul '08

24 Jul '08

[Apologies for duplicates] Dear Colleagues, The RIPE NCC Database Group has now implemented the White Pages functionality discussed in the Database Working Group session at RIPE 56. For those not familiar with the discussions surrounding White Pages, please refer to the document outlining all the details of the implementation in the RIPE Database Document Library: http://www.ripe.net/db/docs.html This document also explains how to have yourself listed in the White Pages. We plan to re-start a clean-up project to remove unreferenced PERSON objects early in September. This will start to delete objects from the database late in September. Anyone who wishes to be listed in the White Pages to avoid deletion should submit an application as soon as possible. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0