RIPE Working Groups

Minutes for the Database Working Group Meeting

RIPE-40, Oct. 1-5 2001, Prague, CZ


A.  Administrative stuff (WW, chair)
	. Volunteering a scribe
		Nigel Titley, PacketExchange Ltd

	. Circulate list of participants
		Done

	. Agenda bashing
		Agenda accepted

	. Status of minutes
		Minutes accepted with minor typos

B.  Actions Items
        . Status of actions
		Unique Handle issue: some progress, documentation is being written.
		lir-partition: being progressed
		Legcy object deletion: being progressed outside the WG (discharged)
		Legacy object issue: being progressed by RIPE NCC
		RFC on RPSL distribution: work needs doing on this, but not in the
			meeting.
		Make DB-help mailing list actually useful: list created but no
			traffic. User guide has seen no progress either.


C.  DB update (RIPE NCC, Andrei R.)                             30 min
        . Operations report
		Presentation available on the RIPE web site.

		Sharp decrease in number of objects due to deletion of unreferenced
		person: objects. More than 3 million objects deleted.
		No problems. Still need further cleanup.

		Half of database is still person: objects, most of the rest are 
		inetnums.

		No major downtime. More than 60% of queries are IP lookups. Domain
		queries have reduced as expected. There is a suspicion that a lot
		of queries are contact harvesting. Also there may be some correlation
		with virus infections and attempts to locate the sources of attacks
		from firewall software. The RIPE NCC will try and investigate.
		It was noted that some tools have a very strange way of using the
		inetd information, and that this may look like contact harvesting.

		Updates are much the same as usual, mostly person: but a lot of inetd:
		Mostly additions, a few deletions. 

		Occasional server crashes, but no downtime.

		Database access checking is in action. Users who require access to
		large amounts of database data need to sign an AUP.

        . Software status
		14/6 RIPE whoise server software 3.0.1 (bug fix)
		14/6 RIPE whois client software 3.0 (interactive and batch mode)
		19/9 RIPE whois server 3.0.2 (bug fixes and improved portability)

		Response time has come down from an average of 1.4 seconds to 0.2 seconds.

	. Projects
		Statistics and consistency. This has been restarted since the new
		database has been in service.

		RAToolSet has been migrated to RIPE NCC, now known as the IRRToolSet.

		RRCC project has stalled, but hope to have results by next RIPE meeting.

        . Migration summary
		Next milestone in 15th October where updates in RIPE-181 will no
		longer be accepted. An annoucement will be made.

		New database reference manual has been published (RIPE-223). User
		manual and Operation Manual will be coming.

		It was agreed not to publish RIPE-181 to RPSL conversion tools to force
		the move to RPSL.

	.Questions
		A question of synchronous updates was raised. This is on the schedule
		for next year. Authentication and logging needs to be addressed.

		A question about performance when several discrete data sources are
		searched was raised. The performance is still good, but not as good
		as might be expected. RIPE NCC will investigate the problem.

		A question about whether ARIN might profitably use the RIPE database
		as the current ARIN output is difficult to use. No discussions have taken
		place as yet. Collaboration would probably improve things. ARIN responded
		that they have no intention of adopting RIPE's RPSL schema or database.
		The issue will be taken offline although ARIN's attitude does not seem
		to be promising.

D.  Removal of "orphaned" person objects (RIPE NCC, N.N.)
        . Report and conclusions (if any  [:-)] 
		Presentation available on the RIPE website.

		Staff churn in the industry results in a proliferation of contact
		data and parallel use of the RIPE database means that an enormous
		amount of data not related to RIPE NCC activities is present in the
		database (mostly domain related).

		There are a number of problems:

		. No clear policy on data cleanup
		. Migration of ccTLDs has been taking place for two years leaving a
			great deal of legacy data.
		. Data privacy has started to assume importance.

		Leading to the following goals:

		. Cleanup of unreferenced AND unmaintained contact information
		. Cleanup of left-over ccTLD legacy data

		Process has led to database reducing from 5M to 1.5M objects. The
		update rate has decreased, whilst the query rate has stayed the same.

		ccTLD domain updates are still being received and are being caught
		and saved, but not actioned.

		Most data left in the database is now relevant to the RIPE NCC
		function.

		The question is now, what should be done to prevent this situation
		from arising in the future. The question was put to the WG. The
		following suggestions were received:

		. The contact information should be a role rather than a person. 
			It was pointed out that it was possible to use roles or
			persons as contact. APNIC are considering making the use
			of roles manadatory. It was not felt appropriate for the
			RIPE NCC to force the use of roles especially as this can
			lead to "buck passing" within organisations, especially with
			the admin-c item.
		. A regular "springclean".
		. Object expiry based on age and usage (object timeout).


E.  Status of the Merit RADB/IRRd
                (Larry J. Blunk, Merit Network, Inc.)
		http://www.radb.net for more information

	. Software
		Version 2.1 of IRRd released on Sept 13 (bugfix and portability)
		RPSL compliant database.
		New user manual, man page, Changelog and release notes.
		FreeBSD/Linux now compiles cleanly (multi-threaded)
		Dependencies on the MRT code base removed or reduced.
		Memory leaks fixed
		Various other significant bugs fixed.
		Now supports PGP and GnuPG
		Command lineoptions to drop process/group levels after start
		IPv6 address support now independent of kernel support
		About 81000 objects at moment.
		Adding support to enable deletion of maintainer for non-payment.

	.Database consistency	
		Cleanup is about to be done.
		. Internal consistency
		. External consistency (removal of duplicate objects, check against
			internet)

		Some problems had been caused by deleting maintainers (on user request)
		without deleting the associated maintained objects.

F.  Report and final discussion: "irt:" object implementation   20 min
                (Wilfried W., RIPE NCC, N.N.)
        . Review of implementation proposal
	  (summary write-up was sent to DB-WG on Aug 23rd)
		See the archives for the review of the proposal
		Hopefully, an initial implementation will be available before
		Christmas 2001.
		Still looking for X509 experience. Please check the proposal
		and verify that it will meet X509 requirements.

        . Review of operational impact (scripts/marketing...)
		We need to make sure that the new object is used. If not used then
		the work done has been wasted.

        . Interworking with "abuse-pointers"?
		Note that the irt: object should not be used for regular abuse type
		purposes (spam etc). Cross checking with the Spam-WG would be useful.

	. Questions
		It was noted that unless the abuse-pointer system is working well,
		then the IRTs will be flooded by spam complaints. 
		A view (from the Spam-WG) was that spam was not being taken seriously
		and that feeding spam complaints into the IRT would be a good thing.
		Other views should be sent to the Spam-WG or the DB-WG.

G.  What is the Universal Whois Project?
                (Mark Kosters, VeriSign Labs)
		More information: http://uwho.verisignlabs.com

		As more RiRs appear, it becomes more important to connect the various
		whois domains together.

		Verisign has committed to undertake an undertaking in agreement
		with ICANN. Currently in information gathering phase. US at present,
		International at some time in the future.

		Requirements:

		. Universal
		. Open source
		. Non-proprietory
		. Distributed

		Protocol to be developed within IETF.
		Policy will be decided by ICANN.

		Whois has no facilities for access control, which is needed for the
		future.
        
		. Questions
		Some concern about the whole thing being US-centric were expressed. It
		was worrying that international consulatation was so far down in the
		list. The best suggestion was to add yourself to the mailing list. 
		A question about individual input was raised. The response was that 
		individual input as well as organisational input would be welcome.
		Concern was expressed that there were differences between mandated
		whois presence (as in RiR databases) was different to voluntary whois
		presence. This can give rise to conflicts between whois domains. Doubt
		was expressed as to whether a single solution will answer the whole
		problem.
		Issues of scaling and of problem limitation are very important.
		
H.  Modification of changed: attribute (RIPE NCC, Andrei R.)    15 min
        . Problem statement
		The "changed" field is used for timestamping in the RIPE DB.
		Useful for IRR troubleshooting, dispute resolution etc.

		Currently not reliable. Few checks.

        . Proposal
 		Generate the timestamp automatically
		Allow user to "tag" the update for tracking purposes

		changed:  

		 a word that has local meaning
		 generated T

		Existing timestamps are preserved. (short form of the date
		accepted).

       . Discussion
		Proposal to automatically use mail address if none supplied. RIPE NCC
		were against this as it meant that the wrong tag might be added.
		Some concern was expressed that the database was adding fields. However
		it was pointed out that this line has already been crossed with other
		fields. It is no longer possible for object owners to make a full check
		of their data. A suggestion was made that another attribute could be
		added allowing the user to maintain his own audit trail if required.
		However, this will require a modification to RPSL itself.
		It was noted that only the latest changed: field will be reliable.
		Concern was expressed about the operation of mirrors. It was established
		that this will not be affected.
		Some people are also using the  field to embed TT
		information. It was to be hoped that the new system would not affect
		this. 
		It emerged that there was a requirement by the RIPE-NCC to access
		the timestamp to check whether inetd objects were created before
		permission was granted. However, they could use the internal record
		of object creation.
		It was suggested that a mechanism for the user to overide the new
		behaviour with his own timestamp if s/he requires. This of course
		renders the new behaviour useless and so a new "timestamp:" (or
		some such) field might be necessary instead.
		It was noted that every incoming mail message is stored and archived
		and that this could provide some means of audit, allowing the
		data owner to retrieve the email that made a particular change. Would
		this be interesting? Concern was expressed that this was just opening
		another can of worms and that it was up to the user to keep a record
		of his own interactions with the database.
		[AP Ripe NCC] Distribute the proposal to the DB-WG mailing list for
		discussion.
		
I.  "organisation:" Object re-visited				10 min
		(George Michaelson, APNIC)
	. Background
		An organisation object was proposed but never adopted. Mostly
		common sense. Interesting field is the own: field which is a list of
		objects which the organisation thinks it owns. A reference within other
		objects (for example inetnem) via a new org: key would allow the reference
		of objects back to the owning organisation. The own: fields could
		be generated automatically.

	. Problem statement
		be generated automatically. The own: and org: fields contain duplicate
		information and possibly one should be removed.
		It was noted that the routing WG had proposed that this new object and
		org: field should be made mandatory.

	. Discussion (and proposal?)
		Problems with identifying owning org: of legacy objects. ARIN is 
		proposing this and is throwing a great deal of resource in
		identifying owner organisation. Again concern was expressed that ARIN
		seemed to be doing its own thing without any consultation with other
		registries.
		If an organisation object were to be created, then there are many
		places it could be used.
		Concern that was expressed that changes would be required to the basic
		RPSL standard and that this would be a very lengthy process. Some
		parts of RPSL are extensible, and it may be possible to use this
		ability to add the new organisation object.
		It was noted that some of the proposed functionality of the organisation:
		object is already provided by the maintainer: object.
		Overloading the mnt-by: attribute gives all the functionality required
		but it would seem to be more appropriate to add the single organisation
		object. 
		It was noted that it should be possible to attach an arbitrary org:
		field. There needs to be some authentication.
		The RIPE NCC DB team felt that automatically generating the own: fields
		would not be practical.
		The comment was made that in the current fluid state of the industry
		this functionality was urgently required.
		It was decided to take this discussion to the mailing list. 

Y.  Input from other WGs
        . "organisation:" object
		See above
	. DNS WG
		The DNS-WG will be writing a short note clarifying that the owner of
		a DNS name can put in a server attribute.

Z.  AOB:
        . Noted that comments about the use of DB addresses for spamming originate
	from the Spam-WG, and not just Rodney.