Database WG Draft Minutes (RIPE48) RIPE48, Amsterdam 5th and 6th May 2004 Draft 2 A. Administrative Matters - scribe (Nigel Titley, FLAG Telecom + Frora) - list of participants - announcements - agenda Accepted - minutes Accepted - "remote participation" coordination (if needed) No requests - meeting schedule for 2005 Thoughts on whether we will be able to manage with only two meetings a year. Please feed back to WW144 Outstanding Actions 43.9 RIPE NCC To track outdated references to the IRRToolSet on the web and correct them. [Complete] 45.5 RIPE NCC To document proposal on organisation object and re-circulate on mailing list. [Complete] 45.6 RIPE NCC To collate responses (to organisation object) and make a start on implementation. [Complete] 46.3 RIPE NCC Add reverse lookup feature for key-cert objects. [Complete] 46.5 WW Coordinate with RIPE NCC to prepare a document summarizing basic assumptions about the use of the database. Presentation at RIPE-47 by WW144. [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.[Ongoing, will be making announcement in a few weeks] 47.2 Randy Bush, Niall O'Reilly Create a short proposal on setting up an appropriate scheme for a simple abuse contact (either "abuse" or "abuse-c") [Covered by presentation, complete] 47.3 RIPE NCC Write a document properly documenting the use of the IRT object for reporting abuse. [Ongoing] 47.4 WW 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, ongoing] B. DB Operational Update (Shane K., RIPE NCC) Presentation on RIPE web site 1. The Organisation object has been created and deployed 2. DNS is now built from the database 3. NONE authentication is now removed. C. ERX Phase 3 (Leo V., RIPE NCC) Presentation on RIPE web site All AS numbers and legacy Class Bs have been migrated. Work must now start on the class C radioactive swamp. D. Value "ZZ" for country: attribute (Engin G., RIPE NCC) Presentation on RIPE web site After discussion there was no real consensus for approving this proposal. The whole business of making country: optional needs to be raised with the Address Policy working group [AP48.1 RIPE NCC] Raise the issue of making country: optional with the Address POlicy working group. E. CRISP/Joint-Whois status . Joint-Whois report (Shane K., RIPE NCC) Presentation on RIPE web site RIPE NCC has not done work on this, in accordance with the wishes of the DB WG but other RIRs have seen this as useful and work has started on it in the LACNIC RIR, with support from APNic who will provide the test environment. [AP48.2 Shane Kerr] To publish the requirements on the DB WG list. . report by Andrew Newton, VeriSign Presentation on RIPE web site Note: The CRISP protocol is actually called IRIS, hence the name of the presentation IRIS is an XML based protocol, specifically for use by registries of Internet resources (not just address registries). IT has a wide range of authentication mechanisms which allow proper authorisation. Referrals are properly handled. An prototype client, PIMMIT, was demonstrated. Some concern was expressed over how much additional operational overhead would be imposed by the IRIS protocol. The response was that the overhead is not excessive. Additional concern was expressed over the use of XML. The response was that prototype clients and servers already exist, and that there are a plethora of tools available for processing XML. The CRISP WG has been at pains to avoid inventing new technology, but has largely used existing building blocks. Fears that underlying databases would have to be modified were also raised and placated. F. support for works of art (Nigel T., FLAG TC) . poetry | haiku | ??? Presentation on RIPE web site It was noted that without internationlisation in the character set, adoption in the AsiaPAC region is unlikely. [48.3 NT13] Proposal should be clarified and the minor issue of tech-c in the poetic-form object clarified. G. irt: / abuse: [60+ min] . proposal by Niall O'R. & Randy B. No Presentation, but later discussion . statistics by Marco H., Niall O'R. and Ulrich K. Presentation on RIPE web site . next steps? (WW144) No obvious consensus on mailing list. Suggested that the mailing list suggestion be implemented to run along side the existing IRT mechanism. Concern was expressed about the manadatory requirement for a PGP object in the IRT object. The CERT community seems to be of the opinion that the PGP attribute may be made optional. The issue of what the database returns is also a problem. The database should return an IRT object by default. The point was made that the vast majority of spam complaints come from tools and that the tool writers were amenable to using IRT. The real problem is to remove the number of email addresses that are returned by a database query and make it obvious which addresses are actually appropriate to receive complaints. Concern was expressed that if the data model was not correct, then retrieving the data in any meaningful form will not be possible. The reply was that the proposal could be considered as an intermediate step to a proper solution involving the IRT object or something similar. The discussion meandered off to consider social engineering to encourage intelligent use of the available tools and data. This was agreed to be a laudable aim but outside the scope of the WG [AP 48.4 Randy and Niall] To refine existing proposal to take into account the discussion during the session and try and acheive consensus on the mailing list. [AP 48.5 RIPE NCC] To implement whatever consensus is reached on the mailing list regarding abuse contact. [AP 48.6 RIPE NCC] To change DB behaviour to return IRT object [AP 48.7 RIPE NCC] To make the PGP attribute optional on the IRT object H. RAToolSet & RPSLng (WW144) . usefulness/consistency Some comments have been received that these tools are sometimes difficult to use, and the parser can return different results under different conditions. A few members of the WG present have used the tools. It was noted that the gcc, bison etc version make a lot of difference. The main issue is that there seems to be no response from the maintainers to problems. The development model seems to be moderately broken. Suggestion to put it in Sourceforge or something similar. The response to this was that the RIPE NCC software team really doesn't have the resource to devote a fulltime (or even part time) maintainer to the toolset. A question is that is it reasonable to try and support it on the range of platforms and compilers out in the wild? It was felt that if the WG felt this was important, then it should mandate the RIPE NCC to either properly maintain it, or to seek a better development model. The RIPE NCC is currently storing up patches and then applying them in batches just prior to a release. This is probably not applicable to the environment in which we find ourselves, where protocols and OSes are changing so fast. The possibility of a complete re-write was raised. Although this is probably not an option the rewrite of the most used parts is a possibility. [AP 48.8 RIPE NCC] To raise the issue on the appropriate mailing lists and seek advice on change of development model. [AP 48.9 RIPE NCC] To apply all available patches to RAToolset etc, and to start a rewrite in ANSI C Y. Input from other WGs See item F Z. AOB