[db-wg] Minutes of DB-WG for the RIPE 69 meeting

Folks

I'm a bit late in sending these minutes out, for which I apologise. 
Please rapidly get any comments back to me.

Thanks

Nigel

-------------- next part --------------
Minutes for DB-WG at RIPE 69, November 2014

A. Administrative Matters [~10 min]
   . Welcome
   . select scribe (thanks to Nigel for volunteering again!)
   . finalise agenda
	No additional agenda items
   . approval of minutes from previous WG meeting(s)
	Minutes. Circulated only very recently so will hold for 3 weeks until approving.
   . review of action list
	AP67.4 [WW144] Take the issue of geolocation to the RIPE NCC Services Working Group as it does not seem to be heavily used. (Ongoing)
	AP67.5 [WW144] To check that the Anti-Abuse Working Group has properly specified both what should be done with mail that is sent to the abuse contact and (possibly) its format. (Ongoing)
	AP67.6 [WW144] To bring to the attention of the Routing WG the fact that the routing data as recorded in the DB is generally very poor (Report by Alexander Azimov) (Ongoing)
	AP68.1 [RIPE NCC] Remove the referral-by attribute (In progress)

B. Working Group Management (Nigel T.) [~10 min]
   . chair replacement procedure
	See presentation
	Procedure accepted
   . WW144 to resign
	Thanks to Wilfried for all his years service.
   . new DB-WG Co-Chairs to take over at the end of session
	Job and Piotr

C. Data Base Operational Update (Tim B., RIPE NCC) [~10 min]
	See presentation.
	All open issues are tracked on Github
	Release Candidate environment is available for at least two weeks prior to release so that full testing may take place.
	Documentation is on line and is tied to each release.
	RIPE Academy is providing DB training
	Abuse-c cleanup is well advanced
		Question: will one of the abuse contact finders be abandoned once this exercise is complete?
		Answer: no for the RIPE NCC region we will only check the abuse-c but the two tools can be merged.
		Question: When will API keys be authenticated by the system
		Answer: It is on the agenda but we are waiting for guidance from the WG
 
D. New DB-Software functionality (Tim B. RIPE NCC) [~35 min]
   (proposed, test, deployment)
	See presentation
   . referral-by deprecation
     - (based on deprecation guidelines)
     - present time table for 'referral-by'
	Removal in three phases over 4 months
   . from "changed:" to "last-modified:" / "created:"
     - explain new attr., examples,
     - timeline for implementation
	Three phases over 5 months.
	Comments (RV) was that such changes should be written down formally in advance.
	Response was that this has been extensively discussed on the mailing list and the details have been available for months.
	RIPE NCC noted that it would be relatively easy to produce such a document.
	[AP69.1][RIPE NCC] Come forward with a self contained document describing the migration 
	of the changed: attribute to the last-modified:/created: attributes  proposal
	Another question was asked about objects in the database which have no changed: lines, what date was it created? The response was that 
	the relevant data will be pulled from the database and added to the object.
	RV asked that there was some syntactic markup to separate system added attributes from user added attributes. It was pointed out that the
	-t flag already tells you this. RV responded that this wasn't enough.
	It was asked whether all the attributes of auto-generated objects should be marked as such. It was agreed to discuss this on the mailing list.
	It was suggested that whatever history is available might be incorporated, including data from ERX and other registries. It was agreed to discuss
	in the mailing list
	[AP69.2][RIPE NCC] Come up with some straw man proposals for doing this

E. Personalised authentication? (Tim B. RIPE NCC, all) [~5 min]
	See presentation
	More detailed proposal following requests on the list and at the last meeting
	WG feedback is needed about how to do this.
	The proposal is to add person authorisation using a Single Sign On authentication.
	Maintainers are also difficult and non-intuitive
	Suggestion is to use roles everywhere. The advantage is that this is consistent and it is easy to see who is who
	An alternative is to have optional persons in maintainer objects
	There will be an issue with migrating existing maintainer objects. Any migration mechanism should ideally be capable of automation.
	Existing tools can be relatively easily modified to check all possible authentication methods.
	Suggestions were presented on how the migration to using roles could be semi-automatically handled.
	All comments gratefully received.
	Adding optional persons to maintainers could be easier to migrate.
	Discussion needs to take place on the WG
	Some comments on the perceived complexity of the maintainer object took place and it was suggested that some good
	concise documents on the maintainer object might help. It was agreed that it would not be a good thing to take away the maintainer object.

F. Maintainer Password resets?  (Tim B. RIPE NCC, all) [~5 min]
	See presentation
	25% of all ripe-dbm requests are password resets
	Rather than removing all authentication RIPE NCC is now adding SSO auto and allowing the member to get access that way instead.

G. "reviving" the WG, active participation (Job S.) [~10 min]
	See presentation
	Participation in the group has dropped off in the last 12 months. Why has this happened?
	Response from RV was that the database is in reasonable shape and is heavily used in production. The fact that
	it doesn't need a lot of modification is actually a strength.
	It was noted that database accuracy is very important and maybe the WG should be thinking about how to improve 
	accuracy of the data.
	It was noted that some of the changes proposed were taking place far too quickly for large organisations to follow.
	It was pointed out by the RIPE NCC training group that many users only use the database 2 - 3 times a year and find it difficult
	to keep current. Rapid changes would make this even more difficult.
	A call was made for IPAM developers to use the RIPE DB API and Softlayer responded that they used it extensively. The RIPE NCC
	said that they were very happy to work with anyone using the DB to improve it and improve the interface into it.
	
Y. Input from other Working Groups and/or Task Forces
	RV pointed out that the Abuse WG really needs to provide proper documentation on the Abuse-C attribute and he suggested that
	it should be made optional until such documentation is produced. It was agreed that this should be chased with the Anti-Abuse. It was pointed out that 
	Anti-abuse TF decided that the abuse-c should come first and the population of it should come second.
	A representative from the Routing WG noted that it is easy for "foreign" prefixes to be entered into the database and these can be used for various
	nefarious purposes. It was suggested that such foreign prefixes should be validated using RPKI. It was asked that the routing WG should
	come back to the DB mailing list with this request.

Z. AOB
	Geolocation.
	Tim Robinson from TXRX communication, saying that he has problems with getting his IP blocks recognised as being from the UK.
	JS agreed with the problem statement. There isn't a global source of accurate geolocation data. Should we make it easier to consume the 
	geolocation data already in the DB? 
	This appears to be an issue with the data providers who can't be bothered to provide the data in the database.
	It was pointed out that browsers generally have a very good idea of location and language and this is a more appropriate source of
	location data than the database.
	[AP69.3][RIPE NCC] To examine and report on possible solutions to improving geolocation data in the RIPE DB