RIPE Working Groups

                               Minutes for the
                       Database Working Group Meeting

                  RIPE-41, Jan. 14-18 2002, Amsterdam, NL
			=09

A.  Administrative stuff (WW, chair)
	. volunteering a scribe
		Nigel Titley took the minutes
	. circulate list of participants
	. agenda bashing
		. Several items received, agenda modified.
	. status of minutes and actions
		. RIPE-40 Minutes to stay as draft for 2 weeks. Comments to the
		mailing list.

B.  DB Update (RIPE NCC, N.N.) (Andrei)
	. Operations report (available from the Ripe web site)
		No substantial changes in database contents since last meeting.
		Database still growing, mostly inetnum and person.
		Unreferenced and unmaintained person objects are growing again
		and need to be sorted out.
		A strange query pattern with a large increase of content data query
		This has been manually blocked and tracked down to a runaway
		script which was fixed.
		60% of valid queries are for inet-num objects.
		80% of updates are new objects.
	. Communications with DB users
		http://www.ripe.net/ripencc/faq/database
		db-help@ripe.net
		Both useful sources of help.
        . bug fixes, re-writes, platform compatibility
		. RPSL object library now provides functions for object parsing
		and syntax checks. Has been rewritten and can be used standalone.
		Written in C but perl wrapper also available.
		Binary download available.
		. status LIR-PARTITIONED PA (PI) now available and facilitates
		LIR IP address management. Mulit-level assignments are no
		longer necessary. Avalable in beta.
		. irt object now available (see below) Available in beta.
		. DB code available for Linux, Solaris and FreeBSD
	. future plans
		. Auth checks across multiple databases
		A proposal will be circulated for examination.
		. Real time updates
		No proposal, but is being considered. Views on the priority
		of this requirement would be welcomed.
		. Automatic database cleanup
		The current proposal (remove unreference and unmaintained
		person objects) needs some changes. Notifications should be
		sent before deletion. Referenced objects should never be deleted.
		However, maintained objects will now be removed. This is slightly
		controversial as it removes people who could be useful even though
		they don't own any objects. The fact that such objects are still
		being created points to obsolete scripts still running. A suggestion
		was made that checking the maintainer attribute of the maintained
		but unreferenced objects would result in a few culprits being
		identified.
		The WG gave a mandate to the RIPE NCC to continue with the cleanup
		process.
		. Prototyping RPSL extensions (ipv6, multicast)
		. Further improvment of DB software
		. Documentation(!)
	. Main events
		. Migration to RPSL/v3 completed
		. New whois web interface is now online.
		. DB Consistency and Statistics project is now online
		. RRCC is resumed (RIPE-201)
		. IRRToolSet support, documentation and bug fixes. Please
		comment on requested features.

	[AP-41.1 WW] To send list of proposed updates to mailing list for WG
		members to vote on. Deadline 3 weeks.

	A proposal to allow referencing external objects (particularly as-sets)
	in "import" objects was received from C&W. It was agreed to discuss this
	on the mailing list. 

	[AP-41.2 C&W] To send their proposal to the mailing list for discussion.

C.  DB consistency and Statistics project (RIPE NCC, Can Bican)
	. Motivation
		. Data gets outdated
		. Early software was more tolerant
	. Goals
		. Provide suggestions to make data more consistent
		. Trace the inconsistencies
		. Provide necessary tools
	. Checks
		. Unreferenced person/role (25%)
		. Duplicate objects (3%)
		. Various invalid inetnum objects (overlaps, no status, hierachiacal)
		. Weak maintainer authentication (none and mail-from)
	. Results
		These can be obtained by sending to auto-dbcon@ripe.net

D.  IRT object implementation (RIPE NCC, Andrei)
        . implementation report, last-minute adjustments
		. Provides contact information of a CSIRT
		. Provides public keys
		. Can be referenced from inetnum objects
		. New argument (-c) to whois client
        . how to use and promote the new features?
		. Create irt object pointing to CSIRT
		. Add mnt-irt attribute to inetnum
		. Use whois -c to find the most specific inetnum pointing to
		to irt.
		. The auth attribute is used to add the mnt-irt reference.
		. The object will be created manually, but the authentication
		mechanism needs clarification.

	[AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object.
        [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate
		objects.

	It was noted that many spam complaint scripts trawl the DB for anything
	that looks like an email address. There seems little chance of educating
	the writers of such scripts. The chair of the Spam WG commented that this
	was a real problem.

	It was suggested that the DB should not allow an IRT object to be created
	with weak authentication methods, but Abdrei felt that this was a bad
	idea and that if an irt object was created with auth "none", then it
	probably was not being created by an appropriate person.
                                           
E.  Universal Whois Project (Andrew Newton, VeriSign App. Res.)
		http://uwho.verisignlabs.com/

        . Needs of addressing information as it relates to domains in whois=
.
	Needs have been limited to those who loosely "administer" the internet.
	Some conflicts have been noted, especially in different legal frameworks.
	Emphasis has been placed on providing the mechanisms not setting the
	policy. Here to collect further requirements.
	Questions still arise as to how ro traverse information repositories. 
	Suggestion is to use DNS SRV attribute. 
	Still not decided on how to handle structured queries as there is no
	universal standard, apart from RPSL for routing registries.
	The primary users will be network operators.
	Question of whether to use port 43 or not. New port would allow a fresh
	start, but does the internet really need a new application transport.
	Requirements draft will be submitted to IETF at end Jan 2002.
        . Overview of two technical solutions.
		. LDAP
		. XML
		both available on the web site and are draft RFCs.

	Some discussion took place on the issue of unique handles. The proposal
	is to use URLs as handles, but this is not yet set in stone.
	Comments are welcome.
        
F.  DataBase documentation for the "average" user
	. Requested by Ruediger Volk
	Who could not be present.
	. Problem statement
	Current queries return all the objects related to a query which
	can confuse the naive user. 
	. Proposal
	An end-user document or FAQ is suggested.
	. How to proceed? 
	APNIC has an FAQ already which may be useful.
	Simplified output from the web page
	The issue was raised that selectively omitting returned attributes
	from a whois query was not possible whilst still remaining RPSL compliant.
	However, this would not be an issue for a simple web interface or for
	a more complex whois client. Comments on improvements in this line
	would be welcome by the DB team.
	A proposal that the template object could indicate which attributes
	may be omitted was received.
	[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 Ruedige=
r.
	[AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and adverti=
se
	to the db-wg list.
	A suggestion from the RIPE NCC for a number of simple web interfaces to
	cover various scenarios: "Im being hacked", "I'm being spammed" etc.
	Another suggestion was to use a different port number for a "simple"
	reply.
=09
G.  "changed:" "organisation:" Objects re-visited (tentative)
	. No discussion

H.  Input from other WGs
        . Tools WG
		. Web interface to whois is now available. Any patches should
		be sent back for folding in to the master.
			ftp://ftp.ripe.net/tools

Z.  AOB:
        . Database Mirroring
	ISPs need to copy all DBs into one place in order to do queries. Mirroring
	protocol is there, but currently undocumented. Could this be documented
	at some time? Also mirroring is very primitive and needs to be more
	selective. It was suggested that the use of a "private" tag could be used =
to
	limit mirroring all objects.
	There also seems to some "stickiness" in the mirroring protocol
	which causes the secondary database to always be one transaction out of da=
te.
	The RIPE NCC responded that this was deliberate, to prevent a bad transact=
ion
	crashing both primary and secondary.
	[AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness".
	[AP-41.8 C&W] To formulate their proposals on the list for discussion.
	[AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational
	requirements of using it.
	. Remove MAIL-FROM in maintainer object
		. Start by nagging maintainer owners to remove MAIL-FROM attributes
		. Then disallow updates of any maintainer object with MAIL-FROM
		auth attributes.
	. Introduce reverse indexing on IRT irt-mnt auth and signature keys.
	Note that this cannot be done until the MAIL-FROM auth method is removed.
	. Implement MD5 password authentication
	[AP-41.10 RIPE-NCC] Provide nag message to maintainer owners
	[AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication
	[AP-41.12 RIPE-NCC] Look at general password authentication methods