Draft Minutes for RIPE 45 Database Working Group Meeting A. Administrative stuff (WW, chair) scribe: Nigel Titley Additional agenda items (none) B. Action Items AP-41.9 RIPE NCC (Shane) believes that this is already done and that a pointer should be placed to the document. In addition a "Mirror Managers guide" is needed. Shane to complete. AP-41.12 Remove as PKI etc is ongoing. AP-42.1 Complete AP-42.3 Ongoing. Revise and refine AP-42.4 Larry has implemented this, so close action. AP-43.1 Close. Ongoing activity. Cleanup of unreferenced persons is complete. AP-43.6 Close. Either it has been done or it is dead. AP-43.7 Ownership to C&W (Dave Beaumont) who are seeing some use of external refs by their customers. AP-43.8 AP-43.9 Housekeeping. Ongoing. AP-44.1 New version of dbupdate now supports generated attributes. Deletion of key-cert objects must include the generated attributes. Closed. AP-44.2 Proposal, but not yet submitted to list. Add tech-c and admin-c to key-cert object. Will be included soon. AP-44.3 Ongoing. No action yet. C. DB operational update (RIPE NCC, Shane K.) including status of ERX (Early Registry Transfer) This presentation will probably move to the new operations forum in the future. Note that there are no large changes in the numbers of objects in the DB since the large major cleanup. Inet6-nums are starting to appear. Most updates still come via email. Synchronous updates now amount to about 9%. Majority of queries are still IP addresses, followed by domain referrals. Note to CCTLD managers to try and use the client information that a deferred query includes, to prevent data mining. Tertiary server planned to defend against DDoS and massive failure. Unreferenced person cleanup will take place starting 29th May. Objects unused for 90 days get deleted. Email sent out at 60 days. Restricting this to 2000 per day to prevent alarm and despondency by deleted persons. IPv6 proxy service is live and being integrated in with the other production servers. Queries are only being received from 7 unique query addresses so the service is not being widely used. ERX update. 4 /8s have been transferred. One more trial and then full transfer will take place. Prototype RPSLng server in now on-line. Includes IPv6 and multicast objects. Still a draft standard so the software is liable to change. IRRToolSet changes are being worked on. A draft plan to update the status attribute will be published soon. [AP-45.1 All] Start thinking about what changes may be required in their software to interact with the changes in the status attribute. Proposals for X509 support for the database and lir-portal will shortly be published on the list. [AP-45.1 RIPE NCC] Add Maintainer contact to the ERX mail exchange A question about RIPE-CC being authoritative secondary DNS server for transferred class Bs. Why? Actually, after the transfer this is not required, but if the record is updated, Marvin insists on the RIPE-NCC being added as a secondary. There is no proposal to change this yet. This should possibly be raised in the DNS working group discussion on lameness. D. Quality of contact data (RIPE NCC, Shane K.) The main goal of the project is to measure the quality of the data in the database prior to any attempts to "fix" it. Names, postal addresses, phone numbers are all difficult to check. Email is possible, but not mandatory in the person object. However a check has been run on those available. 80% were ok, the rest were defective in some way. Some of the 80% may fail even so. Applying this to real IP addresses gives about 12% with no valid email address, partly because the email attribute is optional in the person object. It was noted that the email attribute is mandatory in both the APNIC and ARIN regions. Possibly the RIPE region should be the same. It was noted that there is probably no one who cannot obtain an email address during the "bootstrap" phase. WW suggested that email "reachability" should be determined by actually sending an email to the contact address. Leo Vegoda, RIPE NCC, asked whether the "changed" attribute should be revised in some way. It was suggested that the authentication mechanism and date used to modify an object is recorded and the "freshness" of the object be used to indicate how likely the contact data is to be accurate. Should the database quality project be moved to the LIR WG, or should it remain in the DB WG? Concensus was that at least the technical aspects should remain with this group. E. New "dbupdate" (RIPE NCC, Denis W.) DBupdate is the front end processor for updating objects in the DB. It has been modified as a result of feedback by users who wanted more error reporting, particularly on authorisation. Generated attributes are overwritten if necessary and the user warned. Plug in code facilities have been added. From a user's point of view the main change is the improved quality of responses and the acceptance of MIME encoding. Nested Authentication both PGP and PGP/Password are now accepted which allows the creation of route objects with proper authentication (for details see presentation). Detailed authorisation information is returned for each object. Error handling is vastly improved, and an error message should be returned in all cases. Acknowledgement messages should be easier to parse with scripts as responses to individual multiple objects in the original message are seperated by '---'. Note that unrecognised keywords in the subject line will cause warning messages. Testing is done using approximately 500 test updates. The full test will be run after *every* change. Documentation is being written and will be released over the next few weeks, including a full set of error messages. F. DB-SW teams up with... (UniVie-ACOnet, Ulrich K.) The UniVie Netw.Info.Sys This presentation describes how the RIPE DB has been used to document the Vienna University network. Some minor changes to the DB code were required, but nothing significant. [AP45.3 RIPE NCC] To expose their development process more publically to allow code to be made available with more dispatch. G. Discussion: to disallow auth: NONE Should auth: NONE be deprecated, or should the user who wishes to use no authentication be allowed to do so? A document has been sent out, on the list, describing the various issues. Note that database copies dating back for 1 year are kept, and so damaged objects can always be restored. There are some situations where auth: NONE is valid. It might be possible to send a warning back when an object that is protected by auth: NONE is modified. [AP-45.4 All] To comment on auth: NONE on the DB WG mailing list. H. Follow-Up on last meetings issues (Chair, WW144) 30 min Organisation object proposal (RIPE NCC, Shane K.) This is a long standing proposal which has got nowhere fast. There has been some resistance in the past, but there have been several expressions of interest in this object recently, and there seems no reason not to go ahead with this now (although some reservations were expressed about the hierachical nature of the object, and the possible changes required when an organisation undergoes corporate metamorphosis. [AP-45.5 RIPE NCC] To document proposal and re-circulate on mailing list. [AP-45.6 RIPE NCC] To collate responses and make a start on implementation. . status: SUB-ALLOCATED PA (Space.Net, Gert D.) This is going ahead anyway. . reclaim: - Attribute (Space.Net, Gert D.) This is also going ahead. . allowing "generated" attributes in updates (WW et.al.) Complete . Key Certificates to person: role: ? This is going ahead, and a proposal has been received. Y. Input from other WGs WW has not received anything from other WGs, neither has anyone else. Z. AOB: Restructuring of WGs. There are a number of proposals for re-organisation. There will be some effects on the charter of this group. [AP-45.7 All] To think about potential interactions with other WGs and consider who this will affect our charter. Private objects? Do we have any idea of organisations who are adding their own objects to their databases, and is there a means of documenting and registering such practices? [AP-45.8 Dave Beaumont] To email WW to let him know what sort of changes they have made, and to remind him to kick off discussion on the mailing list.