A. Administrative Matters
  	. Welcome
  	. select scribe (Nigel Titley)
  	. finalise agenda
		No additional items
	. approval of minutes from previous WG meeting(s)
		Minutes had been submitted to the mailing list, no comments received
		Accepted as final
  	. review of action list (NT13)

	[AP57.2] [RIPE NCC] Cleanup of forward domain data. Now complete and closed.
	[AP63.1] [WW144] Gelocation proxy. Ongoing
	[AP63.2] [RIPE NCC] UTF-8 compliance. Technically it works but it hasn't been properly
		tested. Not recommended. Discharged.
	[AP63.3] [Dave Freedman] Raise issue of reverse lookup method for aut-num objects on the 
		mailing list to find out if this was a desired feature. Ongoing.
	


B. Data Base Update (Alex Band and Denis Wlison, RIPE NCC)
	See presentation
  	- general update
		Half a billion database queries per month.
		There was an extended IPv6 downtime, but this was caused by connectivity and not
		system problems. It remained accessible over IPv4.
		MD5 hashes have now been hidden and all MD5 hash users have been emailed
		suggesting they update their passwords. Over 8000 bounced mails came back. This
		suggests some decay in data accuracy. Not a lot of effect (roughly 700 passwords changed)
		Plaintext passwords in emails are still an issue, but some steer is needed from
		the community.
  	- geolocation status/implementation
		Now available as an optional (single) attribute in beta as is the language (multiple) 			attribute. 
		Need furthur discussion and testing.
  	- internationalisation
		No policy currently defining when UTF-8 should be used in the database.
		Need to wait for this policy before it can be tested. This needs to be taken up 
		on the mailing list.  
	- projects
		- Whois
			Brand new whois application. Current version is 11 years old. The new service
			is running in parallel with the old one. New version is much more efficient
			and flexible. 94% of queries are handled by the new software. Code will be 
			provided to the other RiRs and will be OpenSource. Written in java.
			The old service will be decommisioned shortly.
		- Update 
			This will be implemented soon and should hopefully lead to a simpler interaction
			with the database to enable new users to get up to speed more quickly. This should
			lead to better data quality. The community does need to help with this.
		- UI
			Integrated with RIPEstat
			Simpler password generation.
			More to follow
		- API
			RESTful queries are being standardised by IETF
			Prototype RESTful redirects to other RIRs are being worked on.

	A question was received about asused. Alex stated that it would be very difficult to re-create
	a command line facility with exactly the same functionality and that it is low (or zero) priority
	at present. 

C. RIPEstat (Robert K., RIPE NCC)
	See presentation
  	- new way of accessing database content
		Note the link between the RIPE DB to RIPEstat referred to above.

	- New widgets
		- Object browser allows you visualise the relationship between objects in the
		database. It is now easy to click through objects and get the information about
		the relationships between them. Personal data is not displayed. History is not
		shown at present but it is possible to display this. Access limits will be applied
		(see presentation). The RIPE NCC would appreciate some feedback on how useful this
		visualisation would be. Training course feedback is generally favourable. Single
		sign-on seems to be a good intermediate access level control.
	
	Comments were that this is fixed display size. The response was that this is a widget and can
	change size as you wish. Other RIPEstat items are being converted to widgets as well.
	A note was made that this could be a useful service and might be used to distinguish 
	between different classes of user (beware: dragons).

D. Review of implementation of auth: filtering
	- filtering of public key information
		No only the MD5 hashes but also the public key information. This was not what was needed.
		It has broken email updates for some members. The response was that this simplies things
		for newcomers. The third possibility is to only show PGP attributes but remove the MD5
		value. There seemed to be some support for this in the room.
		The point was again made that this has broken a lot of automated tools, although noting
		that such users should really be looked at the mailing list and should be contributing 
		to the development. 
		It was agreed that some compromise should reached.
		
Y. Input from other WGs and/or TFs
	- APWG: is there a referral mechanism for inet[6]num in the DB code?
		Should there be a means of referring objects from one RIR or another to allow for
		inter RIR transfers?
		This should not be done at the http-redirect level.
		The IETF is working on this with a proposal to sit on top of the RESTful API and
		provide the redirect. Care has to be taken not to get into loops.
		So the response is that technically it can be done but requires careful
		consideration so as not to cause operational problems.

Z. AOB