Minutes for the Database Working Group Meeting RIPE-40, Oct. 1-5 2001, Prague, CZ Draft A. Administrative stuff (WW, chair) . Volunteering a scribe Nigel Titley, PacketExchange Ltd . Circulate list of participants Done . Agenda bashing Agenda accepted . Status of minutes Minutes accepted with minor typos B. Actions Items . Status of actions Unique Handle issue: some progress, documentation is being written. lir-partition: being progressed Legcy object deletion: being progressed outside the WG (discharged) Legacy object issue: being progressed by RIPE NCC RFC on RPSL distribution: work needs doing on this, but not in the meeting. Make DB-help mailing list actually useful: list created but no traffic. User guide has seen no progress either. C. DB update (RIPE NCC, Andrei R.) 30 min . Operations report Presentation available on the RIPE web site. Sharp decrease in number of objects due to deletion of unreferenced person: objects. More than 3 million objects deleted. No problems. Still need further cleanup. Half of database is still person: objects, most of the rest are inetnums. No major downtime. More than 60% of queries are IP lookups. Domain queries have reduced as expected. There is a suspicion that a lot of queries are contact harvesting. Also there may be some correlation with virus infections and attempts to locate the sources of attacks from firewall software. The RIPE NCC will try and investigate. It was noted that some tools have a very strange way of using the inetd information, and that this may look like contact harvesting. Updates are much the same as usual, mostly person: but a lot of inetd: Mostly additions, a few deletions. Occasional server crashes, but no downtime. Database access checking is in action. Users who require access to large amounts of database data need to sign an AUP. . Software status 14/6 RIPE whoise server software 3.0.1 (bug fix) 14/6 RIPE whois client software 3.0 (interactive and batch mode) 19/9 RIPE whois server 3.0.2 (bug fixes and improved portability) Response time has come down from an average of 1.4 seconds to 0.2 seconds. . Projects Statistics and consistency. This has been restarted since the new database has been in service. RAToolSet has been migrated to RIPE NCC, now known as the IRRToolSet. RRCC project has stalled, but hope to have results by next RIPE meeting. . Migration summary Next milestone in 15th October where updates in RIPE-181 will no longer be accepted. An annoucement will be made. New database reference manual has been published (RIPE-223). User manual and Operation Manual will be coming. It was agreed not to publish RIPE-181 to RPSL conversion tools to force the move to RPSL. .Questions A question of synchronous updates was raised. This is on the schedule for next year. Authentication and logging needs to be addressed. A question about performance when several discrete data sources are searched was raised. The performance is still good, but not as good as might be expected. RIPE NCC will investigate the problem. A question about whether ARIN might profitably use the RIPE database as the current ARIN output is difficult to use. No discussions have taken place as yet. Collaboration would probably improve things. ARIN responded that they have no intention of adopting RIPE's RPSL schema or database. The issue will be taken offline although ARIN's attitude does not seem to be promising. D. Removal of "orphaned" person objects (RIPE NCC, N.N.) . Report and conclusions (if any [:-)] Presentation available on the RIPE website. Staff churn in the industry results in a proliferation of contact data and parallel use of the RIPE database means that an enormous amount of data not related to RIPE NCC activities is present in the database (mostly domain related). There are a number of problems: . No clear policy on data cleanup . Migration of ccTLDs has been taking place for two years leaving a great deal of legacy data. . Data privacy has started to assume importance. Leading to the following goals: . Cleanup of unreferenced AND unmaintained contact information . Cleanup of left-over ccTLD legacy data Process has led to database reducing from 5M to 1.5M objects. The update rate has decreased, whilst the query rate has stayed the same. ccTLD domain updates are still being received and are being caught and saved, but not actioned. Most data left in the database is now relevant to the RIPE NCC function. The question is now, what should be done to prevent this situation from arising in the future. The question was put to the WG. The following suggestions were received: . The contact information should be a role rather than a person. It was pointed out that it was possible to use roles or persons as contact. APNIC are considering making the use of roles manadatory. It was not felt appropriate for the RIPE NCC to force the use of roles especially as this can lead to "buck passing" within organisations, especially with the admin-c item. . A regular "springclean". . Object expiry based on age and usage (object timeout). E. Status of the Merit RADB/IRRd (Larry J. Blunk, Merit Network, Inc.) http://www.radb.net for more information . Software Version 2.1 of IRRd released on Sept 13 (bugfix and portability) RPSL compliant database. New user manual, man page, Changelog and release notes. FreeBSD/Linux now compiles cleanly (multi-threaded) Dependencies on the MRT code base removed or reduced. Memory leaks fixed Various other significant bugs fixed. Now supports PGP and GnuPG Command lineoptions to drop process/group levels after start IPv6 address support now independent of kernel support About 81000 objects at moment. Adding support to enable deletion of maintainer for non-payment. .Database consistency Cleanup is about to be done. . Internal consistency . External consistency (removal of duplicate objects, check against internet) Some problems had been caused by deleting maintainers (on user request) without deleting the associated maintained objects. F. Report and final discussion: "irt:" object implementation 20 min (Wilfried W., RIPE NCC, N.N.) . Review of implementation proposal (summary write-up was sent to DB-WG on Aug 23rd) See the archives for the review of the proposal Hopefully, an initial implementation will be available before Christmas 2001. Still looking for X509 experience. Please check the proposal and verify that it will meet X509 requirements. . Review of operational impact (scripts/marketing...) We need to make sure that the new object is used. If not used then the work done has been wasted. . Interworking with "abuse-pointers"? Note that the irt: object should not be used for regular abuse type purposes (spam etc). Cross checking with the Spam-WG would be useful. . Questions It was noted that unless the abuse-pointer system is working well, then the IRTs will be flooded by spam complaints. A view (from the Spam-WG) was that spam was not being taken seriously and that feeding spam complaints into the IRT would be a good thing. Other views should be sent to the Spam-WG or the DB-WG. G. What is the Universal Whois Project? (Mark Kosters, VeriSign Labs) More information: http://uwho.verisignlabs.com As more RiRs appear, it becomes more important to connect the various whois domains together. Verisign has committed to undertake an undertaking in agreement with ICANN. Currently in information gathering phase. US at present, International at some time in the future. Requirements: . Universal . Open source . Non-proprietory . Distributed Protocol to be developed within IETF. Policy will be decided by ICANN. Whois has no facilities for access control, which is needed for the future. . Questions Some concern about the whole thing being US-centric were expressed. It was worrying that international consulatation was so far down in the list. The best suggestion was to add yourself to the mailing list. A question about individual input was raised. The response was that individual input as well as organisational input would be welcome. Concern was expressed that there were differences between mandated whois presence (as in RiR databases) was different to voluntary whois presence. This can give rise to conflicts between whois domains. Doubt was expressed as to whether a single solution will answer the whole problem. Issues of scaling and of problem limitation are very important. H. Modification of changed: attribute (RIPE NCC, Andrei R.) 15 min . Problem statement The "changed" field is used for timestamping in the RIPE DB. Useful for IRR troubleshooting, dispute resolution etc. Currently not reliable. Few checks. . Proposal Generate the timestamp automatically Allow user to "tag" the update for tracking purposes changed: a word that has local meaning generated T Existing timestamps are preserved. (short form of the date accepted). . Discussion Proposal to automatically use mail address if none supplied. RIPE NCC were against this as it meant that the wrong tag might be added. Some concern was expressed that the database was adding fields. However it was pointed out that this line has already been crossed with other fields. It is no longer possible for object owners to make a full check of their data. A suggestion was made that another attribute could be added allowing the user to maintain his own audit trail if required. However, this will require a modification to RPSL itself. It was noted that only the latest changed: field will be reliable. Concern was expressed about the operation of mirrors. It was established that this will not be affected. Some people are also using the field to embed TT information. It was to be hoped that the new system would not affect this. It emerged that there was a requirement by the RIPE-NCC to access the timestamp to check whether inetd objects were created before permission was granted. However, they could use the internal record of object creation. It was suggested that a mechanism for the user to overide the new behaviour with his own timestamp if s/he requires. This of course renders the new behaviour useless and so a new "timestamp:" (or some such) field might be necessary instead. It was noted that every incoming mail message is stored and archived and that this could provide some means of audit, allowing the data owner to retrieve the email that made a particular change. Would this be interesting? Concern was expressed that this was just opening another can of worms and that it was up to the user to keep a record of his own interactions with the database. [AP Ripe NCC] Distribute the proposal to the DB-WG mailing list for discussion. I. "organisation:" Object re-visited 10 min (George Michaelson, APNIC) . Background An organisation object was proposed but never adopted. Mostly common sense. Interesting field is the own: field which is a list of objects which the organisation thinks it owns. A reference within other objects (for example inetnem) via a new org: key would allow the reference of objects back to the owning organisation. The own: fields could be generated automatically. . Problem statement be generated automatically. The own: and org: fields contain duplicate information and possibly one should be removed. It was noted that the routing WG had proposed that this new object and org: field should be made mandatory. . Discussion (and proposal?) Problems with identifying owning org: of legacy objects. ARIN is proposing this and is throwing a great deal of resource in identifying owner organisation. Again concern was expressed that ARIN seemed to be doing its own thing without any consultation with other registries. If an organisation object were to be created, then there are many places it could be used. Concern that was expressed that changes would be required to the basic RPSL standard and that this would be a very lengthy process. Some parts of RPSL are extensible, and it may be possible to use this ability to add the new organisation object. It was noted that some of the proposed functionality of the organisation: object is already provided by the maintainer: object. Overloading the mnt-by: attribute gives all the functionality required but it would seem to be more appropriate to add the single organisation object. It was noted that it should be possible to attach an arbitrary org: field. There needs to be some authentication. The RIPE NCC DB team felt that automatically generating the own: fields would not be practical. The comment was made that in the current fluid state of the industry this functionality was urgently required. It was decided to take this discussion to the mailing list. Y. Input from other WGs . "organisation:" object See above . DNS WG The DNS-WG will be writing a short note clarifying that the owner of a DNS name can put in a server attribute. Z. AOB: . Noted that comments about the use of DB addresses for spamming originate from the Spam-WG, and not just Rodney.