Minutes of the DB Working group, RIPE 37

Dear All,

Please find attached the first draft of the minutes of the DB Working group 
for RIPE 37. Please let me know if I have made any errors. I'll issue the 
final version in a couple of days time.

Nigel

-------------- next part --------------
                             Minutes for the
                       Database Working Group Meeting

                    RIPE-37, Sept. 2000, Amsterdam, NL
				 1. Draft



Thursday, Sept 14, 2000 at 09:00-12:30
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part I:         WG-Meeting

PI-A.  Administrative stuff (WW, chair)
	. volunteering a scribe
		Nigel Titley volunteered to take the minutes
	. list of participants
	. agenda bashing
		The agenda was accepted (4th draft).
	. minutes distributed
		Minutes as distributed were accepted.

PI-B.  Actions Items
    	. Fwd domain object migration
		Details under the "Input from other WGs heading". Progress
		is being made, and the performance of the database has 
		improved.
	. Follow up on IRT pointer facility
		This was addressed in the meeting

PI.C.  RIPE DB, operations update (RIPE NCC)                    20min
	Presented by Ambrose MaGee of the RIPE-NCC.
	
	Statistics

	There has been continuous growth in the number of objects, as
	usual, excepting the outward migration of domain objects (approx
	200,000) leaving 300,000 objects. This has resulted in person objects
	becoming the majority of the database (71%).  60% of person objects
	are now unreferenced. The majority of these are unprotected. PGP 
	has increased (311 key-cert objects, an increase from 247). The 
	number of protected objects has dropped	and now is only 1.4% of 
	the database. 

	Operations

	Average query rate is about 7 per sec. However this is now fairly
	stable, probably because of the loss of the domain objects. The
	underlying query rate however, is still increasing. The query 
	rate for domains is still high (but many are refered),
	IP obejcts have increased. The update rate is down by 66% since
	July. The vast majority of updates are now for person objects (77%),
	followed by domain and then inetnum.

	There has been no downtime of the database since the last meeting.
	There is now dynamic failover to the backup server. A debt of
	gratitude is owed to the DB maintainance team who do such a
	wonderful job.

	1700 messages are received by ripe-dbm at ripe.net of which the majority
	are mail-bounces. The number of requests for PGP licenses is
	woefully low.

	The database is monitored to make sure that proper use is being
	made of it, and to ensure that its performace is good.

	50% of mntner object requests are denied, mainly because of slow
	response from some ccTLD registires. 124 PGP licenses have been
	distributed to date (much too low).

	Database Consistency Project

		Runs on a dedicated machine. Summary stats are on the Web

	Secondary Sites

		TEST: a playpen machine for testing and training
		BETA new software (RPSL):

	Routing Reality Check

	ARIN legacy Objects

		ARIN expects to transfer some legacy objects to RIPE shortly.

	Database re-implementation

		Most functionality now present. An average of about
		20 downloads for each beta release.

		Live data at reimp.ripe.net (port 43).
		Update to auto-ripe at ripe.net
		
		Information is available on the DB services web page and
		snapshots of the code are available.

PI.D.  IRRd: experiences, registration software weaknesses
                                          (G.Winters, MERIT)     20min
	A presentation was given by Gerald Winters from Global Crossing.
	
	Motivation

		The talk is just to let other people know what we are doing
		and to open the possibility of collaboration.

	GBLX DB Wish list items

		Allocation

		Would like to be able to generate export access lists on a
		 per region basis in order to minimise access list size.

		Eliminating the paper trail

		SWIP templates for ARIN need to be updated. This should
		be able to be derived from the DB.

		IGP support

		This would turn the DB from a global registry to an everyday
		tool (really applies more to RADB rather than RIPE). Makes
		the DB more useful.

		Hide sensitive data

		Need to add security filters on top of the registry so need
		to seperate public from private data.

		Access control granularity

		By object, IRR etc

		Relational DB Backend

		Integrating IRRD with TimesTen backend giving relational
		queries giving better support for allocation registry
		functions.

	RPS-DIST (RFC2769)

		Built a prototype over the summer. The overal reaction seems
		to be good. It scales better and has better security, a
		good RFC. It has more functionality but is more complex.
		The RFC still has some holes which need filling in.

		There are some performance problems. The unit of exchange
		is too small and this results in overhead as all registries
		are consulted. Syntax checking could be an issue unless
		a uniform syntax is specified for main fields and object 
		canonicalisation is repeated at each site, which can be
		expensive. DBs must be transaction version controlled for 
		auth checking.

		General observations are that the protocol is not fully
		dynamic. Rpsdist daemon will not dynamically accept
		new connections. If you want to join the global DB mesh
		you must first register information at a trusted source
		such as IANA or RIPE. Also if a transaction fails no one
		will update your DB until the transaction is overridden with 
		a successful transaction. This can result in queuing and loss
		of transactions. However, it was pointed out that this was
		actually one of the design goals.

		Also detached PGP signatures are not supported (not a show
		stopper). Nothing is specified for the case where a poll
		request cannot be satisfied. There is missing information
		from the "repository" object (needs a snapshot URL). Finally
		although there is a section on "mirror-only" nodes, there is
		no prescribed method for it to join the mesh.

		Despite these minor issues, the RFC is good in the main,
		and it was pointed out that it  could be updated if
		necessary. Gerald felt that some updates will be necessary,
		with which the authers of the RFC agree. It was felt that
		RIPE should be at least tracking this work, and it should
		be added to the agenda for the January meeting.


PI.E.  Activity Plan proposal(s) for next year
	Summary

		Call for activity plan proposals has turned up two
		requests: enhanced security mechanisms, and how to
		represent IPv6 and multicast information in the DB. They
		have been added to the activity plan.


PI.F.  Recommendation on the use of auth. methods in the DB (WW) 10min
        Mechanisms documented on NCC web pages

		NONE, MAIL-FROM, CRYPT-PASS, PGP. All documented on the
		RIPE-NCC web page. No recommendation on which method
		to use.

        Recommendation from the community

		Proposal to write a recommendation from the community
		on which methods to use. 

		There was a feeling that the older methods should be retained
		for some objects, where it was felt to be approriate in some
		cases. It was also felt that the weak methods could be used as
		the start of a chain of trust. Authors for the proposed draft
		will be solicited.

        Operational impact

		A general plea was made to change operational procedures
		to use PGP where useful.

PI.G.  Globally unique handles for person:/role: ? (R. Bush)

        Is there a need for globally unique handles?
	
	At the moment different registries have different handles.
	This can lead to enormous confusion (cf RB366, RB366-ARIN, RB366-RIPE).
	The identifier is just a local identifier within a registry. There
	are a number of reasons for this. The main reason is that
	database formats have not been made consistent.

        What could they look like?

	Examples could be

		<local-id>.<registry>
		Well known net-unique ids (email, pgp etc)
		Socially unique (Nat Insurance no)

	The latter two don't refer to registries, so we are stuck with something
	like the first form. So we need to clean up.

        How to obtain and use such a handle, and for what?

	Registries need to agree on a common format.

	There was a suggestion that any scheme should be hierachical (possibly
	just two levels). PGP key-id was suggested for the <local-id>.

	Part of the problem is lack of incentive to move. 

	The basic technical problem is lack of consistency in wire format,
	so the DBs are unhappy or unable to transfer data between each other.

	The group was asked whether it was worth working on common formats
	for identifiers, and/or wire formats. Some work seems to be being
	done on similar problems (character sets and referrals) although this
	now seems hung. It was suggested that the RIPE community should come
	up with some suggestions for the San Diego IETF meeting.

	Maillist list details will be sent to the DB-WG mailing list.

PI.H.  IRT-Pointer for DB Objects (WW) 10min
	What is this all about?
		Homogenous set of information pointing to CERT team for
		an object.
		A means to explicitly advertise the response team contact
		for an object to allow, for example, abuse complaints
		to be properly targetted.

        Consensus to go ahead?
		It was suggested that a more concrete example would help
		people to decide. There are a couple of examples available
		which will be sent to the list
		
        Which Objects?
		Which objects to apply it to needs deciding.

PI.Y.  Input from other WGs
        CENTR TECH
		Query referrals mechanisms have been devised to allow the 
		delegation of domains (for example).  Sometimes these
		are not being properly used. The top level domain objects
		need to be properly protected and maintained. The RIPE-NCC
		is understandably unhappy to modify data in the DB, based
		on precedent. This is a general problem, should person objects
		be removed if un-referenced. Should junk entries be removed?

		Opinion was divided on whether it was the registry's
		responsibility to clean up the junk, but with the balance
		of opinion being that we should ask the registries to clean
		up, for example, unreferenced person objects after a certain
		amount of time. But procedures should be set up so that
		this is done in a controlled fashion.
	
PI.Z.  AOB:
		Do we want a PGP tutorial next January? No real interest
		but it was unclear whether this was due to apathy, ignorance
		or a general air of superiority.


Part II:        Re-Implementation/Migration TF

	
PII.A: 	New Database implementation
	Presentation by Andrei Robachevsky <andrei at ripe.net> (copy available)

PII.B: 	Re-implementation Task force
	Volunteer was sought to coordinate this (Ulf Kieber). Other 
	volunteers are extremely welcome to help, especially people
	who are running mirrors at present, or who are deriving router
	configurations from the DB. 

	The Task force would need to look at the following items:
		.Test Reports/Feedback
		.Deployment Plan
		.Next steps
		.Logistics