Draft Minutes for the DB-WG session RIPE 47 28th January 2004 A. Administrative Matters - Scribe Nigel Titley (FLAG Telecom) - List of participants - Announcements (live on net) - Agenda Was distributed on the mailing list Additional item on database usability (Randy Bush) - Minutes Draft minutes accepted as true record. All presentations can be found at http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#db - Outstanding Actions [AP-43.9 RIPE NCC] To try and track down some of the outdated references to the IRRToolset out on the web and get them corrected. status: Closed [AP-43.7 Dave Beaumont (C&W)] To produce a short report on what would be useful regarding external references and how to start. status: Closed [AP-45.5 RIPE NCC] To document proposal on organisation object and re-circulate on mailing list. status: Will be ready in 2 weeks or so. Ongoing. [AP-45.6 RIPE NCC] To collate responses (to organisation object) and make a start on implementation. status: Ongoing [AP-46.1 RIPE NCC] Send the RIR requirements for CRISP to the database working group list. status: Closed as superceded by presentation. [AP-46.2 RIPE NCC] Prepare documentation on how to handle reverse DNS for the address space transferred by ERX. status: Notification text to ERX transferees has been improved, and general reverse DNS will be improved. Closed. [AP-46.3 RIPE NCC] Add reverse lookup feature for key-cert objects. status: Ongoing, no progress. [AP-46.4 RIPE NCC] Implement a tag in the database to denote that the network range is no longer valid. status: No progress. Closed. [AP-46.5 Wilfried Woeber] Coordinate with RIPE NCC to prepare a document summarizing basic assumptions about the use of the database. status: Presentation this session by WW144. Ongoing. B. DB Operational Update (Shane Kerr, RIPE NCC) See presentation DB query response time is still well under a second. Note that the increase in ipv6 is not an indication of growth, just much delayed documentation of existing inet6nums. Note the removal of cross notify attributes in February 2004 Note that overlapping objects may no longer be created. Owners of existing objects will be contacted to get them tidied up. C. ERX (Leo V., RIPE NCC) See presentation 29 /8s have been transferred to date. The rest will be complete by late spring. Approx 3000 registrations to be done after that. D. X.509 support implementation (Shane Kerr, RIPE NCC) See presentation This should be the last presentation in this extended series. The RIPE NCC is ready to implement. No comments, so this proposal has been accepted by the group. E. CRISP/Joint-Whois status (Shane Kerr, Engin Gunduz, RIPE NCC) See presentation CRISP/joint-whois allows for a single query to determine information about an IP address range. This is particularly apposite since ERX. CRISP is a new protocol to replace whois. Joint-whois attempts to generate a short-term fix by implementing referral-only servers (joint..net). Concern was expressed (Randy Bush) that joint-whois was yet another interim solution and that focussing on CRISP might be a better use of resources. There appeared to be some support for this view. Operators would probably benefit less from joint-whois than end users, who mainly want the information to complain to the wrong place about spam. CRISP is intended to replace the whois protocol altogether. Currently in Draft format. Will be XML based. IRIS has been chosen as the protocol (which is XML based). Referrals will be client-side so much more scaleable. This implies (possibly) a central referral server, which could be an NRO function. It was hoped to have the drafts ready by end March. RIPE NCC may commit resources to providing a "snapshot" CRISP server. IRIS is scheduled for full verification in August 2004. It was noted that the problem with CRISP may well be the availability of the clients. However the sooner servers are up and running, the sooner the clients will start to be developed. It was suggested that the way forward for the CRISP standard was for the community to comment on the draft proposals, although some doubt was expressed that anything would come of this and that the RIRs should be expending effort on the draft standards. [AP-47.1 RIPE NCC] Set a deadline for the commencement of work on prototype server code, taking into account the likely availability of standards. F. Getting rid of auth NONE (N.N., RIPE NCC) See presentation General concensus seemed to be to accept this proposal (and remove auth: NONE with no warning). G. irt: / abuse: - populating inet[6]nums w/ irt links, DFN, SURFnet (Ulrich K./Marko T.) See presentation - documentation available (WW144 How-to, FAQ) Useful technical HOW-TO published on setting up an IRT object and how to link it to inet6num object. (DFN) http://www.dfn-cert.de/team/matho/irt-object/irt-object-howto.html FAQ on what an IRT object is and how to use it. (SURFnet) http://www.surfnetters.nl/meijer/tf-csirt/irt-object-faq.html - abuse-c: discussion and proposal summary (MarcoH, mch2-ripe) See presentation The proposal was to add a new attribute "admin" to inetnum, inet6num, mnt. This would be a single email address. It was suggested that since the irt object already exists, that more documentation on how to find the correct responsible person/role for a particular IP address would be the useful thing to do. Caution was raised about needing to liase with other WGs before taking action. Attention was drawn to possibly changing the response from the database to make the irt object more easily visible. The irt object could have an "abuse" attribute, and this would be the most appropriate place for it. It was pointed out that abuse encompasses more than just spam, but also includes security aspects. The current irt object is really intended to address this second aspect. More "user" contact is needed. This may be addressed by proper documentation. The issue of whther to provide multiple contacts (with hints) for abuse, or whether to provide a single contact, where the triage is done internally. The multiple contact route needs careful definition, or it becomes difficult to automate the raising of complaints. It was pointed out that the average "user" is not at all au fait with the workings and attributes of the DB, and this must be addressed in some way. COncern was raised that using a referenced object to contain the abuse attribute was too complicated for the average user. It was also felt that setting up an irt object was too complicated. [AP-46.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") [AP-46.3 RIPE NCC] Write a document properly documenting the use of the IRT object for reporting abuse. - whois server: review of (default) behaviour & format (WW144) Omitted as covered in other items - how to get the other WGs involved? Spam? Routing? (WW144) Omitted as covered in other items H. RPSLng status and deployment (Simon L., SWITCH) See presentation RPSLng is usable for multiple protocols RIPE NCC offers a test database, but there are very few (4) real aut-num objects using the new policy attributes. Still needs a bit of work to tidy up the syntax, and operator input is seriously needed. It was noted (Randy) that the operators who use tools to extract their routing configs from the database need to be involved. It was also noted that since changes will take place in the future we should start to think about versioning. Please start trying to use RPSLng. It is not too late to update the specification. I. S/MIME support (Denis W., RIPE NCC) See presentation Note, use only for signing, not encryption. J. Do we need a BCP on "Proper Use of the Registry Database"?? (WW144) Omitted as covered in other items. K. Usability of the DB as a proper package Randy has set up a small instance of the RIPE DB. He has had problems with building the DB, and with populating the empty database. The question is how much support the RIPE NCC should provide to other users of the software. The response from the RIPE NCC is that they try and limit the amount of support that they provide, as their resources are limited, and support is on a best effort basis only. Concern was expressed about tardy releases of new features in the software available on the ftp site. Questions were raised as to how large the potential user base for the this software is? If the software was easier to use would this be wider? And if this is so, is it the RIPE NCC's responsibility to do this. There are no reliable estimates of how many copies are in use, although probably 30 public registries are available [AP-46.4 WW144] To send note to DB WG mailing list to ask how many are using the DB software, and on what platform Y. Input from other WGs None noted. Z. AOB None Actions from this Meeting [AP-47.1 RIPE NCC] Set a deadline for the commencement of work on prototype server code, taking into account the likely availability of standards. [AP-46.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") [AP-46.3 RIPE NCC] Write a document properly documenting the use of the IRT object for reporting abuse. [AP-46.4 WW144] To send note to DB WG mailing list to ask how many are using the DB software, and on what platform