This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Database proposal
- Previous message (by thread): Database proposal
- Next message (by thread): results on Ripe Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrew Crawford
andrewc at nildram.net
Mon Sep 8 15:21:08 CEST 1997
On Mon, 8 Sep 1997, TOB wrote: > The idea is that only the provider and RIPE(and of course the customer > itself) knows the individual assignments. It should be implemented by > hiding individual assignments in the RIPE database for everyone. If a > provider does not take a proper action in e.g hacker cases RIPE should > have the right to identify who the exact user of e.g a /24 is. I disagree with this plan. The advantages of having the user of an allocation readily identifiable vastly outweigh the potential threat from spammers, or from any other marketing activity. Open access to the allocation database is an important factor in keeping registries, and their customers honest. If a customer comes to me requesting address space, I can easily check for any allocation they might already have from other registries, and find out if any space needs to be returned, etc. I can also find out if their existing contact handles are appropriate to the new application, saving me time, NCC disk space, and everyone the hassle of unnecessary duplication of data. In addition, any ISP should be able to determine the source network of an abusive user *immediately* and without beurocratic delay. Lastly, and most importantly, RIPE should not be expected to artbitrate or judge in cases of dispute between ISPs where identity information is requested. To do so would be to enter a particularly unpleasant legal quagmire, which we, as funding contributors, might all find ourselves paying for. Andrew Crawford Operations Engineer Nildram Ltd
- Previous message (by thread): Database proposal
- Next message (by thread): results on Ripe Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]