Final Minutes for DB WG at RIPE 41

Hi, Nigel,

About {AP-41.8 C&W]
>	[AP-41.2 C&W] To send their proposal to allow referencing external 
>	objects in the DB to the mailing list for discussion.
>		Ongoing, no action yet
We made a proposal to allow "import: from SRC::ASN:AS-SET" for using data
from other source of registry data. I haven't seen any formal response from
RIPE NCC yet. This shouldn't affect the database referential integrity but
will make RR closer to a distributed structure. Maybe the status is now
"Complete, pending response from RIPE NCC" ? Agreed ?


About {AP-41.8 C&W]
> 	[AP-41.8 C&W] To formulate their proposals on the list for
discussion.
> 		Complete. No response from C&W.

I think Andrei already responded to my email on this issue (check his e-mail
on 3/11/2002 to the DB-WG).
Basically we all agree to use "ADD + dummy object" action to filter out
non-RPSL object in the NRTM stream. And I believe RIPE NCC already have a
prototype for testing. Thus I considered this item closed. Agreed ? 

Thanks.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net



> -----Original Message-----
> From: Nigel Titley [mailto:nigel at packetexchange.net]
> Sent: Thursday, July 18, 2002 11:39 AM
> To: db-wg at ripe.net
> Subject: Final Minutes for DB WG at RIPE 41
> 
> 
> Folks,
> 
> As I have had no comments following the posting of the 
> minutes in draft
> form to this list and to the Ripe web site, I am publishing 
> the minutes
> in final form (see below)
> 
> Best regards
> 
> Nigel
> 
> 
>                           Minutes for the
>                        Database Working Group Meeting
> 
>                RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL
> 
> 
> 
> Thursday, May 2nd, 2002 09:00-12:30
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> A.  Administrative stuff (WW, chair)
> 	. scribe (offer from Nigel received)
> 	. circulate list of participants
> 	. agenda bashing
> 	. status of minutes
> 	Minutes have been circulated to the list in both draft and final
> 	form and are posted to the 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.
> 		Ongoing, no action yet
> 
> 	[AP-41.2 C&W] To send their proposal to allow 
> referencing external 
> 	objects in the DB to the mailing list for discussion.
> 		Ongoing, no action yet
> 
> 	[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.  
> 		Ongoing, some objects created
> 
> 	[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.7 RIPE-NCC] To investigate soluton for mirroring 
> "stickiness".
> 		Complete, a solution is now available.
> 
> 	[AP-41.8 C&W] To formulate their proposals on the list 
> for discussion.
> 		Complete. No response from C&W.
> 
> 	[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
> 		Ongoing. See presentation below.
> 
> 	[AP-41.11 RIPE-NCC] Look at implementing MD5 password 
> authentication
> 		Complete. 
> 
> 	[AP-41.12 RIPE-NCC] Look at general password 
> authentication methods
> 		Ongoing. No action yet.
> 
> C.  DB update (RIPE NCC, Andrei R.) 
> 	Usual DB update. Presentation available on the www.ripe.net
> 	web site.
> 	. Operational update
> 	70% of queries are for IP addresses, 10% are domain references.
> 	The rest are various, including person.
> 	System is scaling well and average response time is less than
> 	1s, despite a doubling of load over the past year.
> 	50% of messages to ripe-dbm are spam. It is suggested that
> 	a simple spam filter (To: or Cc: ripe-dbm) may reduce this.
> 	Ticketing system to be introduced in the next few weeks.
> 	
> 	. Database developments
> 	MD5-PW scheme introduced, based on md5-crypt. Available on test
> 	database, soon to move into production.
> 	MAIL-FROM now to be deprecated. Notification to go out 
> soon. 4 weeks
> 	later updates will be rejected (except for maintainer object
> 	updates). 4 weeks later submission will be rejected. Finally
> 	4 weeks later the MAIL-FROM attribute will be removed from all
> 	maintainer objects. There is a suggestion that the same thing
> 	should be done with NONE. The meeting formally approved 
> the MAIL-FROM
> 	timeline. The process to start before the end of May.
> 
> 	IRT object has been available since Jan 2002. Two IRT objects
> 	have been created. Creation procedure still needs some 
> development.
> 
> 	DB Consistency and Statistics project
> 	113 reports displaying 34000 inconsistences were produced. 
> 	Please act on these and fix data.
> 	[AP-42.1 ALL] To check own data and correct inconsistencies if
> 	possible.
> 
> 	SYNCUPDATES prototype
> 	Available in test as a syntax checker only so far.
> 
> 	RRCC full prototype is ready
> 
> 	IRRToolset is being managed. Update requests are very welcome.
> 
> 	APNIC will be using the RIPE database code. The procedural
> 	changes needed will be rolled into the main database code.
> 
> 	DB Documentation
> 	Structure and parts of several chapters are ready. Should be
> 	consistent with LIR training.
> 
> 
> D.  Complex authentication scenarios (Alex G. SWITCH)
> 	. Background
> 	There are some scenarios which require multiple signatures. This
> 	has revealed a small bug in the database which has been worked
> 	around.
> 	It is better to sign a clear text update rather than using mime
> 	encapsulation. In the event of multiple signatures 
> being required
> 	the clear text should be signed by the first 
> maintainer, then the
> 	entire email signed again by the second maintainer.
> 	[AP-42.2 RIPE-NCC] To send instructions on multiple credentials
> 	to the DB working group mailing list.
> 
> 
> E.  Discussion on "hiding" credentials (RIPE NCC, N.N.)
>         . "shadow password" concept
> 	The idea is to not include the encrypted credential in the whois
> 	response. This prevents "brute force" attacks. However, 
> this breaks
> 	with DB tradition of returning all attributes of all 
> objects when
> 	requested and means that the DB can be the primary repository of
> 	the data.
> 
> 	A proposal for a two level authentication scheme was received
> 	with full access for the DBA, but no password access from the
> 	general public. It was pointed out that this was a 
> wider issue than
> 	just the RIPE community, but was also being discussed 
> in the RPSLng
> 	working groups. It was also pointed out that packages 
> are available
> 	which can attack digested passwords.
> 	The very valid point was raised that those who have 
> problems with
> 	weak authentication methods, should use strong ones (eg PGP).
> 	Objects to this were that Windows users had problems 
> with PGP and
> 	its "complex" interface.
> 	[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 possibilies 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.
> 
> F. IRT Object creation process
> 	The technical implementation is in place. Procedures 
> need some work.
> 	Two IRT objects are registered so far.
> 	Objects need some authentication, to give them some cedibility.
> 	A "trusted introducer" currently provides 
> authentication and labelling
> 	when an object is created. This may need updating. 
> There is a meeting
> 	on the 23 - 24th May in Copenhagen on Computer Security IRT 
> 	coordination.  Attend if appropriate.
> 
> G. Org object?
> 	This has been discussed in the past. Were people still 
> interested
> 	in creating this object? APNIC and ARIN also carry 
> these objects.
> 	This might be used in the registration of inet-nums. 
> The role object
> 	partially answers this need, but cannot be used for an 
> admin-contact.
> 	An org object could also be used to make a LIR object 
> more visible
> 	and allow remote updating. The question also arises as 
> to whether
> 	the owners of PI space could create org objects.
> 
> H. Migration of objects between registries
> 	This is affecting legacy address space which pre-dates 
> RIRs. This
> 	is currently in the ARIN database. It is proposed to 
> migrate this data
> 	to the appropriate geographic RIR database. A great 
> deal of inter-RIR
> 	liasison has already taken place. A number of 
> approaches are possible,
> 	ranging from moving the data completely, using the 
> referral mechanism,
> 	carrying all data in all databases etc.
> 	The thing that mustn't happen is to delete more up to 
> to date data in
> 	the non-authoritative database in favour of old data in the 
> 	authoritative database.
> 	It has been suggested that the "delegated" attribute be used to
> 	implement. This would only be used for inet-num and 
> as-set objects.
> 	The issue was raised that one of the top level domain 
> servers is in
> 	the 192.0.0.0/8 block, and deletion of the route 
> objects for this would
> 	be disastrous. The response to this is that there was 
> no intention
> 	to move route objects, just inet-num objects.
> 
> I.  Input from other WGs
>         No other input
> 
> J.  AOB:
> 	No other business.
> 
> 
>