RIPE Working Groups

                             Minutes for the
                       Database Working Group Meeting

                   RIPE-38, January 2001, Amsterdam, NL
				 1. Draft



Wednesday, January 24, 2001 16:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part 1:         Joint Session with Routing-WG


Thursday, January 25, 2001 09:00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part 2:         DB-WG Meeting

P2-A.  Administrative stuff (WW, chair)
	. volunteering a scribe
		Nigel Titley
	. list of participants
	. agenda bashing
		The agenda was accepted (2nd draft).
	. minutes distributed
		Minutes as distributed were accepted.

P2-B.  Actions Items
    	. Fwd domain object migration
		Covered under "Operations update"
	. IRT pointer facility
		Covered in the agenda

P2-C.  RIPE DB, operations update (RIPE NCC, Ambrose Magee)     20min

	This presentation is available on the Ripe-NCC web site.
	[RIPE-NCC please insert URL] http://www.ripe.net/

	Of particular note is the very poor uptake of PGP. Everyone is
	*strongly* encouraged to take up the offer of PGP licenses for
	users of the database.

	Queries have levelled off at approx 7/sec. Updates have dropped
	from 21/min to 4.5/min, largely due to reduction in number of
	domain objects.

	Attention is drawn to the tuning of the batch queues to hold
	back updates that include person objects, as these can involve
	delays whilst the database is re-indexed.

	Note the new RIPE DB FAQ.

	It was noted that aut-num objects without maintainers will have
	a maintainer object controlled by the RIPE-NCC added. Owners of
	such objects will have to contact the RIPE-NCC to allow access
	to their objects.

	A question was asked about RPS-Dist. Ambrose confirmed that this
	has not been worked on.

	A question was asked as to whether we should migrate unreferenced
	and unmaintained person objects. Concensus was that this could be
	considered. 

	It was suggested that there should be a workshop on running a workshop
	for NRTM users. It was felt that contact between the RIPE NCC was
	sufficiently good that this wasn't a problem.

	Concern was expressed about the use of unreferenced person objects
	by other parties. It was thought that the use of unreferenced 
	person objects was not a problem, provided such objects had a 
	maintainer. There was *no* suggestion that all unreferenced person
	objects should be deleted (or not migrated).

P2-D.  CERT Object, IRT pointer (Wilfried Woeber)
        . proposal
	To allow a registry to register details of a CERT contact to
	be associated with a group of resources (usually IP addresses).
	
	Proposal is to add a new property mnt-irt to inetnum and autnum
	objects which points to a new object, similar to a maintainer
	object.

		irt:	NCC-IRT-RIPE
		address:
		phone:
		fax-no:
		email:
		admin-c:
		tech-c:
		upd-to:
		mnt-ntfy:
		auth:  {cryptpw |pgpkey }
		mnt-by: 
		signature: KEY-REF- [single][mandatory]
		encryption: KEY-REF- [multiple][mandatory]
		changed:
		source:

	Note that the mnt-by property may be a self reference. The signature
	and encryption properties may be used to send and receive email to
	and from the team. Note that these values are not added to the local
	key ring, but are simply used when communicating with the IRT Team.

        . feed-back from TF-CSIRT Barcelona
	Wide degree of support from some 45 representatives of IRT teams

	A suggestion was made that the role object be extended to include
	the extra properties of the irt object. Some doubt was expressed
	as to whether this would allow the sort of extended whois search
	that could be useful in the future for rapid tracking of incidents.

	Wilfried will write up the proposal formally, and will submit it
	to the WG for approval.

	This proposal is being experimentally implemented in version 3 
	of the database.

P2-E.  Unique Handle Proposal (RIPE NCC, Joao Damas)
	This presentation is available at
	[RIPE-NCC Please insert link]

	This proposal attempts to address the problem of there being
	no standard for a a globally unique handle proposal.

	Some concerns were expressed with the problems of deleting objects
	which are referenced elsewhere. One answer to this is to say that the
	customer is responsible for their own data. However this removes
	the ability to maintain consistency on object deletion.

	Also need to address the question of reusing these unique names (do
	we or not?), and whether or not to have a central registry.

	A spurious question was raised over the use of the dash in the
	unique handle and possible confusion with AS-macros. It was pointed out
	that all AS-macros start with the string "AS-" which enables them
	to be easily spotted.

	Next step would be for the proposal to be fleshed out and presented
	at the next ARIN meeting. [AP Joao Damas]

P2-F.  Followup on Re-Implementation/Migration TF
                                (Wilfried Woeber)  15 min
	This presentation was made to the Routing WG session and may be
	found at [RIPE-NCC Please insert reference here].

	The first cut over date is April 23 2001 (at which point updates
	may be made in RPSL). Final cut over is in October, when the database
	will be running fully in RPSL.

	If any RIPE-NCC customer wants to delay this cut over, then a well
	documented and substantiated technical case must be submitted at least
	a month before the cut over. Such a case will have to be very strong
	indeed, as a number of other initiatives are being held up by the
	delay to the cutover, and more than a year's notice has been given.

	The RIPE-NCC has been asked to make a first formal release of the new
	database software and will do so, even if bugs remain.

	A suggestion was made that RIPE NCC should make recommendations on
	how to properly specify external references. It was decided that this
	was a possible work item for the future but not immediately relevant.

PI.Y.  Input from other WGs
        .LIR WG
		Proposal from the LIR working group allowing the status field
		to have a value of lir-allocated. This has the suppport of the
		LIR WG, and was accepted as a formal request. No objections
		to the RIPE NCC being asked to go ahead with this.
		[AP Joao Damas]

PI.Z.  AOB:
        . Legacy address space
		Migration of these address objects from the original ARIN
		database. ARIN is in the process of arranging for the provision
		of in-addr.arpa servers for legacy address space. For addresses
		which are in use in Europe, these will be transferred to RIPE.
		Problems occur where a record exists in both the ARIN and RIPE
		databases. A decision needs to be made which one to drop (there
		are about 1000 objects falling into this category). A suggestion
		was made to compare the timestamps, and also to publish a
		list of the objects in dispute. It was decided to throw the
		question to the mailing list as a first attempt to get an
		answer. [AP Wilfried Woeber]
		
	. Referential integrity override
		How to overide the DB checks on updating person objects which
		have objects referring to them. This has to be handled manually	
		at the moment. The suggestion is to allow a special update
		mechanism. There was some suggestion that the removal of the
		name as a primary key could solve this, but this was rejected
		due to the possibility of typos when typing in a handle. It
		was pointed out that the simple solution is to delete the object
		plus all the referencing objects and then re-create them. Some
		people felt that this was a clumsy approach.
		[AP Karsten Schiefner To write to RIPE-NCC specifying the problem]