Minutes of the DB-WG, RIPE 54, Tallin Draft 2 A. Administrative Matters (5 mins) * Scribe - Nigel Titley * Distribute participants list * Finalise agenda Accepted * Approve minutes from RIPE 53 Minutes accepted * Review of action list 53.5 WW144 Wait for the formal consensus of the ENUM Working Group on renaming NON-REGISTRY to OTHER (in the ORG object type) and then ask the RIPE NCC to make the change. [Done] 53.4 WW144 Alert Routing Working Group about the implications of the ASN16 to ASN32 transition on tools. [Done] 53.3 RIPE NCC To make sure that if there is a "flag day" for ASN32 behaviour then the planning and introduction for this is done properly and advertised appropriately. [Done] 53.2 RIPE NCC To check and point out this requirement to various software developers: including but not limited to irrtoolset, quagga etc. [Done, but see below] 53.1 WW144 Close AP50.1 (To make the country attribute on inetnum and inet6num optional and multiple) and properly reformulate it. [Done 2/1/2007] 51.9 RIPE NCC To contact a subset of the spam tool writers and make sure that they are aware of the change in behaviour as required by AP51.8 [Done] 51.8 RIPE NCC To properly implement DB behaviour to always return "irt:" object on address queries, if it exists. [Done, but see below] Remote Participation Jabber chat provided by RIPE NCC B. Database Update (Jos Boumans, RIPE NCC) See presentation Database Team - 2 new members of the team 32bit ASN - Has been done to support new numbers. FLAG day was 2/1/2007. 14 are in use currently. Quagga now supports it. Query behaviour for IRT Objects - Changes still in process. Only 1% of inetnums are actually covered by IRT objects with abuse-mailbox. Final change to add -c flag is backward incompatible and needs discussion. Crypt-pw deprecation - Started 30/11/2006. 3900 initially in database. 550 conversions in 2 days. Crypt-pw finally removed 22/2/2007. Documentation - Manuals have been brought up to date and one new manual written. It is proposed that the manuals are not released as RIPE documents to enable more timely release of the manuals. There was general support for this. It was also suggested that if necessary, sections could be left as RIPE documents. For example the User Reference Manual sections could remain as RIPE documents. [AP54.2 RIPE NCC + Chairs] To check through documents and decide how to split manuals into RIPE and non-RIPE documents. Whois IPv6 - Now fully integrated into whois. Operational update - Slight increase in queries but otherwise business as usual. RIPE-DBM - Two new members of the team. See presentation for details. It was noted (Gert Doering) that the lack of references to IRT objects are due to the lack of -c behaviour and that we should go ahead with the implementation of this by default. This action has taken considerable time and we would like to have a flag day very shortly. [AP54.1 RIPE NCC] To go ahead with final implementation of IRT query behaviour, within 4 weeks. C. Task-Force on Data Protection Issues (Jochem de Ruig, RIPE NCC) See Presentation First meeting 7th May at Tallinn. The whole thing has been made necessary by changes to EU data protection laws. Proposal to ensure that every object has a maintainer. [AP54.3 RIPE NCC] Go ahead and investigate ensuring that all objects are maintained, including timeline and notifications. Submit proposal to the Working Group. It may be necessary to de-automate the creation of maintainer objects. An opt in "white pages" facility within the RIPE Database for industry related persons is suggested. Some expressions of support for this. [AP54.4 RIPE NCC] To investigate the provision of a "white pages" facility for industry related persons. Discussion on the country attribute. Support was expressed for retaining the mandatory status of the country field as it is valuable information. On the other hand the data is being used to generate other sets of data and hence is being processed in a data protection sense. The fact that this information is of suspect value was also raised. The issue was raised (Leo Vegoda) that the purpose of the data is unknown and undocumented and therefore the information in the database can be used to derive unwarranted and unsupported conclusions. He suggested that the relevant information be provided from the organisation object, where of course it is optional. Perhaps what we are looking for is an optional location attribute. The location information is also obtainable from the ORG object and perhaps this should be mandatory. The RIPE NCC has found the country attribute useful during the ERX project. We need to define better the actual required function of this attribute. It was noted that the country attribute is extremely helpful for research purposes (for producing the IPv6 report for example) and this information is generally helpful for the operation of the network. [AP54.5 DP-TF] To analyse better the function of the country attribute in inetnum and inet6num. D. Treatment of Orphaned Objects (Denis Walker, RIPE NCC) See presentation Originates from the data protection issue (data must be relevant to the purpose of the RIPE DB). Steady rise in unreferenced objects. It was noted that a small number of people actually want to be in the database and that the removal notice should offer the means to remain in the database for those who want to remain in the database just so that people can remain if they wish. A work around to retain your person object might be to create a poem object. Reuse of NIC handles caused some comment, as maintainers might use a NIC handle not understanding that they had possibly changed. It was suggested that objects should be quarantined rather than deleted. Concern was expressed that there may be external references into the database. The issue of NIC handles shared with the ARIN database was also raised. General consensus was that we do need to get rid of the unreferenced objects but there was no consensus. [AP54.6 RIPE NCC] To summarise the discussion and write up for the mailing list Y. Input From Other Working Groups/Task Forces Resource Certification Task Force (impact on RIPE Database, if any) [Nigel Titley]. For full CA-TF report please see: http://www.ripe.net/ripe/meetings/ripe-54/presentations/Certification_Task_Force.pdf There will probably be an effect, but this is not yet known. DNS: Retire "rev-srv:" attribute in inetnum: (Peter Koch, DENIC) See presentation. - Summary is that this is no longer needed as it also appears in the domain object. - The top 5 maintainers account for the majority of objects mainly because this is hard coded in their software. [AP54.7 RIPE NCC] To prepare a plan for removal of the rev-srv attribute from the inetnum, inet6num objects. Z. A.O.B WW144 asked if the mandate and/or the chairs of the group needed changing. There was no enthusiasm for replacing the clown at the front or of changing his mandate.