Minutes of the Database WG
RIPE 56 (Berlin)
Thursday, 8 May. 16:00-17:30

A. Administrative Matters

    * Welcome
    * Select a scribe (Nigel T)
    * Finalise agenda
    	Agenda accepted
    * Approval of Minutes from WG session at RIPE 55
    	Minutes approved. Move from draft status
    * Review of action list (Nigel T)
    	[AP55.2] To be taken offline
    	All the rest will be dealt with below

B. Database Update - Jos I. Boumans, RIPE NCC

	* See presentation
    * Actions from previous meetings
    	AP54.3 Mandatory MNT-BY. Code is completed but two issues which means that before can be deployed much more rigorous testing needed to be done. Ongoing
    	AP54.7 rev-srv deprecation. Needs a database schema change. Will be released at the same time as AP54.3. Ongoing
    	AP54.4 White pages. New org-type and will be maintained by WG-Chairs.
    	AP54.6 Clean up unref'ed person objects. Started. 400k remain. Same problem as AP54.3. Start by implementing AP54.4. Monitor object weekly from outside DB and remove if unreferenced for 3 weeks. Ongoing
    	AP55.1 Add mnt-irt to LIRportal. This is not possible at the moment. It has been added to the rewrite schedule for the portal which will take place late this year or early next. Ongoing
    * Future of RIPE DB
    	DB Team would like to pause and reflect and decide on how the database should change to reflect current requirements. 
    * DB Terms & Conditions
    	Now clearly defined. RIPE NCC can now remove data as required by law. Discharges AP55.3.
    * Stats
    	Lots of pretty graphs. See presentation.
    * IRIS
    	Very lightly used. Prototype code. Feature frozen. Suggestion to deprecate. It is suggested that there is much higher use in the domain area. DENIC are intending to release a client and server, but orientated to the domain side. Possibly sometime this year. The RIPE version just proxies to the RIPE database. There is less than 1 query per day. It was agreed that it should be deprecated. 
    * RRCC (Routing registry Consistency Check)
    	Suggestion to integrate with RIS and deprecate as standalone service. Agreed.
    * Mirroring RR
    	No protocol, so breaks down when syntax changes.
    	Attributes with no equivalents result in data being dropped.
    	Only about 12% of queries are actually valid.
    	5% of valid queries are for route objects and so this question is being asked of the routing WG too.
    	Proposal is to build a joint referral service. Replies would be in the format of the remote DB (which may be problematic). 
    	The point was raised that it is impossible to do CIDR type searches directly on the ARIN database and so the mirroring service is useful.
    	A desire was expressed for a little more data on how frequently sync is lost (1 - 2 times a month) and how quickly it can be recovered (depends on the other registry). 
    	Some users of the service raised the point that returning results that are not in RPSL would be a problem. They suggested that this would be a far worse problem than returning stale data.
    	 
    	
C. Follow-Ups

    * Task-Force on Data Protection Issues
    	Summary report will be presented tomorrow in the plenary
    * Contact Data Quality/Requirements Discussion
    	Nothing appropriate for the moment
    * Resource Certification Project
    	The point was raised that the CA-TF work was a focus for actions by lawful authority to remove items from the database. Would we want to record all such actions. This is properly the domain of the DP-TF and some progress on similar topics has already been made.
    	[AP56.1 DP-TF] To consider the action to be taken when legal authority requests the removal of data from the database, and in particular whether records of such actions should be recorded.
    	It was noted that 2008-04 will result in more ROA data for the DB using data derived from the certification effort.

D. High Avalability SW Update for IRR - Yasuhiro Shirasaki, NTT

    * Using ripe-whois and our experimental syncronization trial
    	See presentation
    	General enthusiam for the work done. The improvements in speed are partly due to the original code being some 7 years old. This gives further impetus to the RIPE DB team to be allowed time to think and reflect on the database re-write.

Y. Input from Other Working Groups and Task Forces
	None

Z. A.O.B
	None