Gentlefolk, Please find the first draft of the DB-WG minutes. Comments, as always, are welcome. Nigel Minutes Database WG RIPE 55 Amsterdam Draft 1 A. Administrative Matters * Welcome * Select a scribe (Nigel T) * Finalise agenda (Agenda accepted) * Approve minutes from RIPE 54 (Approved) [AP54.1 RIPE NCC] To go ahead with final implementation of whois IRT query behaviour (-c), within 4 weeks. Deployed on 1st August after testing. Complete. [AP54.2 RIPE NCC + Chairs] To check through and decide how to split the Database manuals into RIPE and non-RIPE documents. Placeholder document RIPE-419 now points to technical manual. Complete [AP54.3 RIPE NCC] To go ahead and investigate ensuring that all objects are maintained, including timeline and notifications. Submit proposal to the Working Group. Discussion continues on when to implement (hopefully soon). [AP54.4 RIPE NCC] To investigate the provision of a "white pages" facility for industry related persons. Ongoing [AP54.5 DP-TF] To analyse better the function of the country attribute in inetnum and inet6num. Possibly related to the restructuring of the addressing information. However still unclear. Suggested that it should be related to the ultimate point of management of the resource. Ongoing. [AP54.6 RIPE NCC] To summarise the discussion on orphaned objects and write up for the mailing list Ongoing. No objection to proceding with Phase 2 and 3 and removing the objects. [AP54.7 RIPE NCC] To prepare a plan for removal of the rev-srv attribute from the inetnum, inet6num objects. Ongoing B1. Database Update - Jos Boumans, RIPE NCC * Operational update (See presentation) * Status of CRYPT-PW retirement * Removal of orphaned objects B2. DB-Software Developmen Activities * restructuring of documentation set Now complete * modification proposals (maintainer to become mandatory) See presentation [AP55.1 RIPE NCC] Add the feature to the LIRPortal "allocation editor" to include the "irt-mnt" attribute. C. Follow-up on: * Task Force on Data Protection Issues Nothing further to report * Resource Certification Project Ongoing. Nothing concrete likely before next April. D. Improvements to the DB Software - Yasuhiro Shirasaki, NTT See presentation. (High availability IRR systems) This is important in relation to a research project on anti prefix hijacking. Used RIPE whois-server as base system due to its speed and scalability. Uses NDBCluster to provide high availability database. However current performance still not adequate. Memory and CPU upgrades should help (4 -> 8GB RAM). Will be implementing offsite redundancy soon. Coverage is basically for Japanese prefixes at the moment but will be extended. In use by several JP ISPs at the moment to filter hijacked prefixes. E. A Case for NRTM for IRR Updates - Raymond J., Elisa, FI * 1075 peering session, 509 unique AS:ses See presentation. Extensively peered, so aut-num object maintenance is an major overhead. Tool XIRR gives contact information, traffic and advertisement information NRTM needed in order to keep the local copy up to date. F. A Review of the "changed:" Attribute - Peter K., DEnic, DE * syntax, semantics, quality of info in changed: ? Problem with changed: attribute. If it is present (even historical copies) then no new changed: line is needed. This casts some doubt on the utility of the changed: line. It cannot be relied upon as a reliable change history of the object or even as the latest change of the object. It is suggested that the changed: attribute should be changed: maybe by enforcing a timestamp for non-null changes. Maybe just maintain the creation and last modification dates? What about ensuring accuracy (a timestamp to say "this record was accurate on this date"). What about data protection issues on personal data? It is possible to produce virtually any variant of this from the database. A full audit trail of object modifications is maintained within the database but is generally only produced in response to a court order. Note that hostmasters actually use these attributes despite their dubious value. [AP55.2 Peter K] To find out what the changed: line is used for and come up with a possible way forward. Will need coordination with the DP-TF. Y. Input from Other Working Groups and Task Forces * Contact Data Quality/Requirements Discussion [Anti-Spam-WG] Continue with this in the DP-TF * "Dot-Notation" for ASN32 [Routing-WG] Some people are not happy with the Dot-Notation for ASN32. Conflict with router RE parsing. No consensus in the Routing-DB so not a lot we can do. Very few ASN32s have yet been issued. However it not an insignificant change. IRRToolset has been patched to allow the dot. The Dot-Notation is still only a draft RFC so may not end up turning into a full RFC anyway. At least one major router vendor has already adopted the Dot-Notation. Z. A.O.B. * External object removal requests (Malcom H.) The issue here is where a legal request might arrive to remove an item from the DB. If this is likely to happen, how should the RIPE NCC respond? At present there is no law that might mandate this, but one might come along. The RIPE DB covers far more than the EU, and this could create a conflict of interest (or even a diplomatic incident). Important that all be aware that this sort of thing is being proposed by certain elements within the EU and we should perhaps think about this. There is clearly a job for the RIPE NCC communications group to make it clear to appropriate bodies what the function of the database actually is [AP55.3 RIPE NCC]. Current RIPE NCC policy on information requests is to first point to the public data, and then if more is required, then require a court order from a Dutch judge. We clearly need to discuss this, but it probably needs discussing in a wider scope but it is very important to have arguments prepared beforehand.