Draft Minutes DB-WG RIPE 43

[Nigel Titley nigel@localhost]

I'm sure I posted this set of minutes, but I can't find it on the
mailing list.

So here goes again.

Errors and problems to me. I'll give it 2 weeks and then issue the final
version.

Nigel

                       Database Working Group Meeting
				Minutes (Draft 1)


               RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR



Thursday, Sept. 12, 2002 09:00-12:30
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A.  Administrative stuff (WW, chair)
	. scribe (offer to take notes received from Nigel)
	. circulate list of participants, agenda bashing
	. status of minutes
          [ see http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html ]
	. All presentation slides are available on the RIPE NCC web site.

B.  Action Items
        . status of actions 

	[AP-41.1 WW] To send list of proposed updates to IRRToolSet to 
	mailing list for WG members to vote on. Deadline 3 weeks.
		Expired and superceded by AP-43.6 and AP-43.9

	[AP-41.2 C&W] To send their proposal to allow referencing external 
	objects in the DB to the mailing list for discussion.
		Superceded by AP-43.7 and AP-43.8

	[AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object.
		Ongoing, some work done.

	[AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate 
	objects.  
		Complete. IRT objects are being created (4 so far) and no
		problems being reported with process.

	[AP-41.5 WW] To put together a group to put together a short guidance
	document to guide reference document writers. This team to 
	include Ruediger.
		Ongoing, no action yet, nothing from Ruediger.

	[AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and
	 advertise to the db-wg list.
		Ongoing, no action yet

	[AP-41.9 RIPE-NCC] To document the mirroring protocol and the 
	operational requirements of using it.
		Ongoing. Some work done.

	[AP-41.10 RIPE-NCC] Provide nag message to maintainer owners using MAIL-FROM
		Complete. 

	[AP-41.12 RIPE-NCC] Look at general password authentication methods
		Ongoing. No action yet.

	[AP-42.1 ALL] To check own data and correct inconsistencies if
	possible.
		Closed

	[AP-42.2 RIPE-NCC] To send instructions on multiple credentials
	to the DB working group mailing list.
		Complete. Instructions are now on the RIPE web site.

	[AP-42.3 RIPE-NCC] To investigate the issues involved in shadow
	passwords and multiple level authentication schemes.
	
	[AP-42.3 Larry Blunk] To investigate the problems of multiple hashed
	passwords and the possibilities of embedding an ID within the hash and
	to submit a proposal to the working group.
	A proposal came from Janos to embed such information in the remarks
	field.

C.  DB update (RIPE NCC, Andrei R.)
        . operations report
		Statistics
			Slightly more objects (1.6M)
			80,000 users on average
			18q/s average, peaking to 65q/s
			2 updates per second average

			Still some growth in unreferenced personal objects. Need
			garbage collection process.

			70% of queries are for contact information

			Updates pretty average apart from spike in mntner object
			caused by removal of mail-from authentication

			Back-end problems solved. Performance issues with long
			queries is still to be resolved. Otherwise scaling well

		User support
			6 support staff shared with other software projects

			Introduced anti-spam filter for mail to ripe-dbm (mail
			routed to folder) since 20th May 2002

			Added ripe-dbm ticket system (shared with hostmaster)

			MAIL-FROM phasing out process. 1500 maintainers missed the
			deadline. High fax load on DB staff. Robot now in place.

		Developments
			New MD5-PW authentication scheme. 41% of maintainers
			are using it.

			New status values for intetnum6 are not now generated.

			DB consistency and statistics project is now generated useful data
			RRCC full prototype is now up and running

			IRRToolset. New version 4.7.3 released. Mostly bug-fixes.

			The database user manual "Getting Started" has been published.
			(Dummies guide to the RIPE Database).

			Real Database user's manual is being progresses

			IRT Document has been published (functionality and procedures)
	
		Plans
			Further improving of server software (Error reporting,
			performance, and configuration management).

			Support auth checks across multiple registries

			IPv6 and multicast support

			Automatic database cleanup (if object is not referenced
			then delete after a certain time (following nag messages to
			user)). There are other possibilities

			[AP43.1 RIPE NCC] Look at other possibilities for database
			cleanup.

			Additional user support (Documentation, Sync and Web interface)

		Main Events

			Improvements in security (MD5 and MAIL-FROM)

			Documentation and User support

			Web and syncupdate interfaces.


D   Web interface and Syncupdates for DB (RIPE NCC, Can Bican)

		Currently updates are via email
			Hard to automate
			Difficult for beginner

		Syncupdates allows online updates to database, web interface
		built on top of this
			TCP based
			Extensible, maintainable, same functionality, easy to use.

		Minimal client (HTTP) can be used

		Notifications are sent by email as usual

		WebUpdates is a prototype of an update client which allows
		adding, deleting and updating of an object. Only password
		authentication. Passwords are stored via cookies.

			No PGP authentication
			Multi-line attributes not properly handled
			Only one object may be updated in a submission

		All suggestions and feature requests are welcomed.

		http://webupdates-test.ripe.net
		http://syncupdates-test.ripe.net

		Probably one month before coming into production (syncupdates)
		Webupdates can be earlier, but please send comments to the db tools
		email address.		

E.  Database Consistency Project Statistics (RIPE NCC, Shane)

		This refers to data that can be seen as incorrect merely by 
		looking at the database itself (eg not routing inconsistencies)

			Changes in rules
			Abandoned data
			User error

		Examples
			Non handle admin-c
			Syntactic errors
			Missing or incorrect status attributes
			Unreferenced person objects
			Unreferenced maintainer objects
			CSIRT for no networks
			Unreferenced PGP key

		Also non-authoritative Data
			Prehistoric inetnum (non-RIPE)
			Objects in unprotected space
			Possibly unauthorized route objects

		Abandoned objects
			Unresponsive maintainers (both LIR and non-LIR)
			Outdated contacts

		Solutions

			Reports
				RRCC reports
				Database consistency reports

				Really only helpful for actively maintained objects

			Restrict Input
				Many of these checks already but will soon include
				integrity checks and RPSS checks

				Does not address current problems

			Revocation
				Allow higher level maintainer to delete objects
				lower in the hierarchy. (Currently can only be done
				by ripe-dbm).

				Unresponsive maintainers? Use another maintainer, or
				delete maintainer?

			Cleanups
				RIPE NCC implementation of WG decision
				Has been done in the past successfully.


		Discussion

			Normally starts on the mailing list, generating proposals
			which are then voted on at the RIPE meeting.

			Opinions
				Why spend a lot of resources to clean it up? It will 
				never be completely clean? Only 5% garbage.

				Difference between structural problems and operational
				problems. 

				Garbage can prevent the generation of accurate reverse
				delegation zone files, and address allocation reports.
				Even 5% garbage can render these useless.

				Registration of contact information can be really
				useful, even if not related to operational data. Should
				we be removing this data if it is useful? However, 
				privacy issues now pertain to this data.

				We should also be wary of using the DB as a general
				key-server.

		
F.  "Early Registration Transfer" (ERX) Project (Andrei, RIPE NCC)
	. Introduction
		ASN and IP registration inherited by ARIN from Internic
		Pre-RIR
		Non-geographical

	. Goals and Phases
		Transfer of DB records and conflict resolution
		Transfer of associated documentation
		
		Phase 1 ASN registrations

		Phase 2 IPv4 registration

	. AS number migration
		ARIN only (419 ASNs) just created and protected in the RIPE DB
			Completed 21st August

		ARIN & RIPE (conflicting data, no RP) (87 ASNs) merge and lock. Resolve
		conflict and then unlock
			Completed 21st August

		ARIN & RIPE (with RP specifications) (177 ASNs) manual 2 week conflict
		resolution prior to transfer
			Completed 21st August
					
		30% of notification emails bounced.

		Lessons
			Don't use August..... 
			Often no evidence. Makes resolution very difficult in 
			cases of dispute.
			Do not lock objects. They may be in use.
			Some people only wake up at the deadline

	. IP V4 migration
		47 /8s to be transferred

		Conflicts are likely to be more complex.

		Transfer of DNS reverse delegations.

		Group 1 (ARIN only)
			Create and protect in the RIPE DB

		Group 2 (Exact match between ARIN and RIPE, except for contact and
			description)
			Resolve conflicts and then merge (do not lock)

		Group 3 (RIPE does not match ARIN)
			If NCC allocation then keep in RIPE
			Otherwise delete (after response time)

	. Discussion

		Thanks for the RIPE NCC from ARIN for their cooperation

		Human matching of records cannot necessarily be done by machine. 
		Records that obviously match on visual inspection may not be easily
		matchable automatically.

		Two weeks (especially in August) is not enough time to resolve conflicts

		[AP43.3 RIPE NCC] Provide detailed action plan to the WG before
		implementing Phase 2.

		Trying to obtain authorization  from contacts in the ARIN database is
		likely to be difficult, as in many cases the authoritative data is 
		the RIPE database. Hence it may be necessary to extend the time for
		resolution of conflicts.

		What happens to IPv4 objects that are in an undefined state after the
		process? They will remain locked until the holder emerges. At which
		point the appropriate procedures will be invoked.

		Is there any chance of getting information about what IP objects
		will be transferred, prior to the actual transfer process?
		[AP43.4 RIPE NCC] To produce a list of requirements for such a list.

		Is there a possibility of automatically aggregating eg /24s in the ARIN
		database to the appropriate aggregated object in the RIPE DB? Probably
		not, as there don't seem to be many such objects. This will probably be
		a manual process.

		A suggestion that more resource be allocated to the IPv4 migration
		than was allocated to the ASN migration.

		[AP43.5 WW] Set up a task force to go through some test cases before
		hand. It should report on the mailing lists (DB and LIR) within 4 weeks.
		(Wilfried Woeber, Nigel Titley, Joao Luis Damas at least)

		Are there any requirements from the outside for target dates? No fixed
		date, but should get it done as quickly as possible.
		
G.  IRRToolSet Development Brainstorming (+ external refs?)
        . how to find out who is using what?
		A few people are... one at least is using a home-brew set of tools

		It was noted that those who are using the toolset are using it together
		with other tools. This may have to be taken into account.

		Some things are missing
			eg Support for zebra

		[AP-43.6 ALL] Those who have requirements to send to IRRToolSet@localhost

		What tools do people find useful?

		[AP-43.9 RIPE NCC] To try and track down some of the outdated references
		to the IRRToolset out on the web and get them corrected.
			
	. External reference

		Who needs it? Need at a minimum things like AS-sets
		which are referred to in the RFC. Need a list of things for which it
		makes sense and those for which it would be insane (Ruediger Volk)

		The status of external reference in the RPSS RFC is "out of document
		scope", although a possible mechanism is described.
		There is a clear need for this, and the C&W registry is using this
		syntax.	It is also needed in order forms etc (and is already included
		in some forms from some providers). The RPSS working group needs
		waking up to properly resolve this issue. Should the DB be prepared
		to accept this syntax? No real performance issues (Andrei) and not
		a real problem. The RPSL-dist informal proposal suggests a new 
		"registry" object.

		[AP-43.7 Ruediger Volk] To produce a short report on what would be
		useful and how to start.
		[AP-43.8 RIPE NCC] To investigate how much effort would be required to
		add this functionality to the RIPE DB.


Y.  Input from other WGs
        . None


Z.  AOB:
	. Organi[sz]ation object proposal
		Examples would be a local registry which could be well described in
		such an object.

	. IRT object
		There are only 4 such objects. However no one has had problems creating

Attachment: signature.asc
Description: This is a digitally signed message part