Minutes for the Database Working Group Meeting RIPE-41, Jan. 14-18 2002, Amsterdam, NL Draft 0.1 A. Administrative stuff (WW, chair) . volunteering a scribe Nigel Titley took the minutes . circulate list of participants . agenda bashing . Several items received, agenda modified. . status of minutes and actions . RIPE-40 Minutes to stay as draft for 2 weeks. Comments to the mailing list. B. DB Update (RIPE NCC, N.N.) (Andrei) . Operations report (available from the Ripe web site) No substantial changes in database contents since last meeting. Database still growing, mostly inetnum and person. Unreferenced and unmaintained person objects are growing again and need to be sorted out. A strange query pattern with a large increase of content data query This has been manually blocked and tracked down to a runaway script which was fixed. 60% of valid queries are for inet-num objects. 80% of updates are new objects. . Communications with DB users http://www.ripe.net/ripencc/faq/database db-help@ripe.net Both useful sources of help. . bug fixes, re-writes, platform compatibility . RPSL object library now provides functions for object parsing and syntax checks. Has been rewritten and can be used standalone. Written in C but perl wrapper also available. Binary download available. . status LIR-PARTITIONED PA (PI) now available and facilitates LIR IP address management. Mulit-level assignments are no longer necessary. Avalable in beta. . irt object now available (see below) Available in beta. . DB code available for Linux, Solaris and FreeBSD . future plans . Auth checks across multiple databases A proposal will be circulated for examination. . Real time updates No proposal, but is being considered. Views on the priority of this requirement would be welcomed. . Automatic database cleanup The current proposal (remove unreference and unmaintained person objects) needs some changes. Notifications should be sent before deletion. Referenced objects should never be deleted. However, maintained objects will now be removed. This is slightly controversial as it removes people who could be useful even though they don't own any objects. The fact that such objects are still being created points to obsolete scripts still running. A suggestion was made that checking the maintainer attribute of the maintained but unreferenced objects would result in a few culprits being identified. The WG gave a mandate to the RIPE NCC to continue with the cleanup process. . Prototyping RPSL extensions (ipv6, multicast) . Further improvment of DB software . Documentation(!) . Main events . Migration to RPSL/v3 completed . New whois web interface is now online. . DB Consistency and Statistics project is now online . RRCC is resumed (RIPE-201) . IRRToolSet support, documentation and bug fixes. Please comment on requested features. [AP-41.1 WW] To send list of proposed updates to mailing list for WG members to vote on. Deadline 3 weeks. A proposal to allow referencing external objects (particularly as-sets) in "import" objects was received from C&W. It was agreed to discuss this on the mailing list. [AP-41.2 C&W] To send their proposal to the mailing list for discussion. C. DB consistency and Statistics project (RIPE NCC, Can Bican) . Motivation . Data gets outdated . Early software was more tolerant . Goals . Provide suggestions to make data more consistent . Trace the inconsistencies . Provide necessary tools . Checks . Unreferenced person/role (25%) . Duplicate objects (3%) . Various invalid inetnum objects (overlaps, no status, hierachiacal) . Weak maintainer authentication (none and mail-from) . Results These can be obtained by sending to auto-dbcon@ripe.net D. IRT object implementation (RIPE NCC, Andrei) . implementation report, last-minute adjustments . Provides contact information of a CSIRT . Provides public keys . Can be referenced from inetnum objects . New argument (-c) to whois client . how to use and promote the new features? . Create irt object pointing to CSIRT . Add mnt-irt attribute to inetnum . Use whois -c to find the most specific inetnum pointing to to irt. . The auth attribute is used to add the mnt-irt reference. . The object will be created manually, but the authentication mechanism needs clarification. [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. It was noted that many spam complaint scripts trawl the DB for anything that looks like an email address. There seems little chance of educating the writers of such scripts. The chair of the Spam WG commented that this was a real problem. It was suggested that the DB should not allow an IRT object to be created with weak authentication methods, but Abdrei felt that this was a bad idea and that if an irt object was created with auth "none", then it probably was not being created by an appropriate person. E. Universal Whois Project (Andrew Newton, VeriSign App. Res.) http://uwho.verisignlabs.com/ . Needs of addressing information as it relates to domains in whois. Needs have been limited to those who loosely "administer" the internet. Some conflicts have been noted, especially in different legal frameworks. Emphasis has been placed on providing the mechanisms not setting the policy. Here to collect further requirements. Questions still arise as to how ro traverse information repositories. Suggestion is to use DNS SRV attribute. Still not decided on how to handle structured queries as there is no universal standard, apart from RPSL for routing registries. The primary users will be network operators. Question of whether to use port 43 or not. New port would allow a fresh start, but does the internet really need a new application transport. Requirements draft will be submitted to IETF at end Jan 2002. . Overview of two technical solutions. . LDAP . XML both available on the web site and are draft RFCs. Some discussion took place on the issue of unique handles. The proposal is to use URLs as handles, but this is not yet set in stone. Comments are welcome. F. DataBase documentation for the "average" user . Requested by Ruediger Volk Who could not be present. . Problem statement Current queries return all the objects related to a query which can confuse the naive user. . Proposal An end-user document or FAQ is suggested. . How to proceed? APNIC has an FAQ already which may be useful. Simplified output from the web page The issue was raised that selectively omitting returned attributes from a whois query was not possible whilst still remaining RPSL compliant. However, this would not be an issue for a simple web interface or for a more complex whois client. Comments on improvements in this line would be welcome by the DB team. A proposal that the template object could indicate which attributes may be omitted was received. [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. A suggestion from the RIPE NCC for a number of simple web interfaces to cover various scenarios: "Im being hacked", "I'm being spammed" etc. Another suggestion was to use a different port number for a "simple" reply. G. "changed:" "organisation:" Objects re-visited (tentative) . No discussion H. Input from other WGs . Tools WG . Web interface to whois is now available. Any patches should be sent back for folding in to the master. ftp://ftp.ripe.net/tools Z. AOB: . Database Mirroring ISPs need to copy all DBs into one place in order to do queries. Mirroring protocol is there, but currently undocumented. Could this be documented at some time? Also mirroring is very primitive and needs to be more selective. It was suggested that the use of a "private" tag could be used to limit mirroring all objects. There also seems to some "stickiness" in the mirroring protocol which causes the secondary database to always be one transaction out of date. The RIPE NCC responded that this was deliberate, to prevent a bad transaction crashing both primary and secondary. [AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness". [AP-41.8 C&W] To formulate their proposals on the list for discussion. [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. . Remove MAIL-FROM in maintainer object . Start by nagging maintainer owners to remove MAIL-FROM attributes . Then disallow updates of any maintainer object with MAIL-FROM auth attributes. . Introduce reverse indexing on IRT irt-mnt auth and signature keys. Note that this cannot be done until the MAIL-FROM auth method is removed. . Implement MD5 password authentication [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners [AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication [AP-41.12 RIPE-NCC] Look at general password authentication methods