RIPE 49 Meeting Database Working Group Date: Thursday 23 September 2004 Time: 09.00 - 10.30 Date: Thursday 23 September 2004 Time: 11.00 - 12.30 Location: Medici Ballroom DRAFT Minutes --------------------------- Draft Agenda A. Administrative Matters B. DB Operational Update (Shane Kerr, RIPE NCC) C. ERX Report [196/8, 198/8] (Leo Vegoda, RIPE NCC) D. IRRToolSet software maintenance (Shane Kerr, RIPE NCC) E. Routing Registry Courses (Rumy Kanis, RIPE NCC) F. CRISP Update (Shane Kerr, RIPE NCC) G. IRT / Abuse-c roundup (Marco Hogewoning) Y. Input from other WGs Z. AOB --------------------------- A. Administrative Matters In the absence of Wilfried Woeber, Nigel Titley will chair this session. Scribe: Ziya (RIPE NCC) Jabber scribe: Marco Hogewoning Minutes from the previous WG session approved. --------------------------- Action points: 46.5 (Wilfried Woeber) Coordinate with RIPE NCC to prepare a document summarizing basic assumptions about the use of the database. Status: ongoing. 47.1 (RIPE NCC ) Set a deadline for the commencement of work on prototype server code, taking into account the likely availability of standards. Shane Kerr: We'll be giving a detailed presentation on CRISP separately. Status: discharged. 47.3 (RIPE NCC) Write a document properly documenting the use of the IRT object for reporting abuse. Shane Kerr: We talked to people who have actually written documents on how to use IRT objects. The RIPE NCC looked through those documents, made sure they're properly edited. We also posted links to documents describing the best current practices on the RIPE NCC Database web pages. Status: post pointers to these documents on the mailing list and then the action item can be closed. 47.4 (Wilfried Woeber) To send note to DB WG mailing list to ask how many are using the DB software, and on what platform. [Done, but no response, closed] 48.1 (RIPE NCC) Raise the issue of making country: optional with the Address Policy working group. Shane Kerr: This happened a number of times, and a discussion took place on 09-22-2004. Leo Vegoda: the result is an Address Policy WG action point to follow up on the list. Status: closed. 48.2 (Shane Kerr) To publish the requirements on the DB WG list. Shane Kerr: We had a presentation on RIPE 47 about CRISP and Joint Whois. The community asked the RIPE NCC not to do any work on a Joint Whois server, but focus on CRISP instead. We have done that. Other RIRs are still interested and pursuing Joint Whois server. Because of that interest, the RIPE NCC wrote and published some requirements on this. Other RIRs are not comfortable with publishing the requirements as they are right now. I would like to leave this ongoing until we can reach an agreement in the RIR community. Status: ongoing 48.3 (Nigel Titley) Proposal should be clarified and the minor issue of tech-c in the poetic-form object clarified. The issue was that the poem object was missing a technical contact field. I have posted a proposal on the mailing list, a typo in the original proposal document was thus fixed. It was suggested that an IRT maintainer attribute be added to the poem object. There was no response to this suggestion. Action item: RIPE NCC to implement the poem object in the RIPE Database. This also includes the migration of the currently existing objects, about 140. 48.4 (Randy Bush, Niall O'Reilly) IRT abuse: To refine existing proposal to take into account the discussion during the session and try and achieve consensus on the mailing list. Marco is going to give a detailed run-down on what has been happening on the mailing list, in a later presentation. 48.5 (RIPE NCC) To implement whatever consensus is reached on the mailing list regarding abuse contact. Nigel Titley: There was no consensus reached yet. I propose we reach consensus today. This action is thus discharged. 48.6 (RIPE NCC) To change DB behaviour to return IRT objects by default. Shane Kerr: this is ongoing. 48.7 (RIPE NCC) To make the PGP attribute optional on the IRT object. Status: ongoing 48.8 (RIPE NCC) To raise the issue on the appropriate mailing lists and seek advice on change of development model. 48.9 (RIPE NCC) To apply all available patches to RAToolset etc, and to start a rewrite in ANSI C 48.8 and 48.9 will be presented separately in more detail and would then be considered discharged --------------------------- B. DB Operational Update (Shane Kerr, RIPE NCC) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-update.pdf) A more detailed Database Handout has been posted at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-handout.pdf C. ERX Phase 3 (Leo V., RIPE NCC) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-erx.pdf) All AS numbers and legacy Class Bs have been migrated. Work must now start on the class C radioactive swamp. Neil O'Reilly: Glad to hear that the ERX process was tuned to address the feedback from the users involved. There were problems introducing name servers in the beginning because of restrictions implicitly introduced that we didn't know about. Several of our zones were hit by these restrictions resolving which caused us extra delays.. Leo Vegoda: I apologise for the delay. It was due to our making changes in the internal procedures of the RIPE NCC which will improve the process of similar projects in the future. D. IRRToolSet software maintenance (Shane Kerr, RIPE NCC) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-irrtoolset-handover.pdf) The IRRToolSet software has been handed over to the ISC for future support and maintenance. The RIPE NCC will continue to provide client support. E. Routing Registry Courses (Rumy Kanis, RIPE NCC) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-rr-training.pdf) Rumy has presented information about the Routing Registray Courses the RIPE NCC is organising. F. CRISP Update (Shane Kerr, RIPE NCC) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-crisp-update.pdf) A more detailed handout on CRISP is available at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-crisp-handout.pdf The areg draft is being finalised and moved to standards-track RFC. A server prototype is being developed by the RIPE NCC using the Verisign reference implementation. The initial implementation will be a proxy to the Whois database. An outreach activity to Whois client authors is planned. --------------------------- G. Possible Solutions for Registering Abuse Contacts: Abuse-c roundup (Marco Hogewoning) The Anti-spam WG asks the Database WG to take some timely action to improve the availability of abuse contacts for IP addresses allocated through RIPE: 1. to publish an explicit abuse contact address where possible for every address; 2. to lower the profile of other addresses currently in the database and published through whois, which were never intended for the abuse function. Proposals: * A. modify the IRT (or other) object to include an explicit 'abuse-email' attribute and to remove the mandatory requirement for PGP or similar authentication (or introduce a similar new object with those properties); and * B. modify the default behaviour of the whois interfaces to find and present an abuse address if there is one and to suppress other e-mail addresses. Questions/comments Neil O'Reilly: it is helpful that we have clear input from the anti-spam WG. We must add a distinguished attribute to the IRT objects and the same distinguished attribute should be added to the person: and role: objects as well because that increases the usefulness of the attribute for those who don't have an IRT object in place. The amount of work needed to add the same attribute to multiple object classes is probably not significantly higher. Adding abuse-c: to inet[6]num: objects is a good idea for completeness, but it would be better to take advantage of the existing aggregate points (role:, person:) in the database. Marco Hogewoning: wouldn't it be better to implement the attribute as optional in inet[6]num: objects instead of tech-c:? Neill O'Reilly: this is rather a 'completeness' thing, let's focus on the advantage instead. Daniel Karrenberg: isn't putting abuse-c: in inetnum: objects feature creepism? It will create user confusion. Maybe it would be better to implement it at the aggregation points only. Question from Jabber: implementing the attribute in multiple ways might be confusing for (client) tool authors. They need exactly one way to retrieve abuse information from the database. Neill O'Reilly: there should be a query interface (API) to the database which hides the actual underlying database structure and gives answers to queries for abuse information. We should promote this 'shrink-wrapped' interface to tool writers so that they don't have to invent multiple ways to retrieve the required information. Neill O'Reilly: database users should not be forced to add a new object (ie, IRT) to the database in order to publish abuse information about they resources. abuse-email: should be part of the person:/role: objects. Daniel Karrenberg and Randy Bush voiced their agreement on this. Consensus declared on proposal A (that the abuse-email: attribute should be added to the IRT and person/role object) Shane Kerr: I wanted to make sure we've got consensus on the proposed modification in the server's behaviour. Consensus declared on proposal B (that the server should suppress the return of all email addresses by default, except the abuse-email if present). Neill O'Reilly: we also need to promote the new behaviour to client tool implementers so that they can understand the change and deliver better information to the customers of their products. [AP49.1 RIPE NCC, ANTI-SPAM WG] To convey this new behaviour to known contacts in the anti-spam tool writing community Daniel Karrenberg: the WG needs a regular update on the penetration of the abuse attribute in the DB. Also, we not only need to educate the users about the change in the use of the database, but also put emphasis on the importance of populating the DB with abuse records and keeping them up to date. [AP49.2 RIPE NCC]: give updates about the number of abuse records in the Working Group. Neill O'Reilly: we need to be careful when introducing and managing these changes. There were unexpected side effects in the past when introducing changes asked by the WG. Shane Kerr: we are going to put together a document about how to introduce the changes. Further discussion is going to happen on the mailing list. We were contacted by several client authors, so we can inform them about the changes. [AP49.3 RIPE NCC] To produce a document detailing the programme for introducing the changes. Leo Vegoda: should the email addresses in mntner: objects be suppressed as well, in addition to the int[6]num: objects? R�diger Volk: email addresses should not be suppressed from domain: objects. Shane Kerr: the default behaviour should be changed on inet[6]num:, route: but not on domain objects. Consensus reached about proposals A and B. [AP49.4 RIPE NCC] To implement the abuse-email: attribute in the irt, person and role objects. X. RIR Data for the IRR (R�diger Volk) (http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-rir-data.pdf) R�diger Volk proposed that RIRs publish relevant data using applicable RPSL through IRR. The data would include complete list of ranges of allocated address space, potentially including prefix lengths. A lengthy discussion emerged but no conclusion was reached. There was a general feeling that this was unnecessary as this data was already available elsewhere. The webcast archive is available at: http://www.ripe.net/ripe/meetings/ripe-49/webcast-files/db-2.wmv Y. Input from other WGs No input. Z. AOB No other business.