Dear Database group At present the RIPE database is quite open, which means that it potentially can be used as a marketing database. My proposal is that only allocations are shown to everyone e.g the 195.41.0.0 /16 below. There is sufficient information to contact the provider in e.g hacker cases. 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. Best Regards Torben Bajlum Tele Danmark inetnum: 195.41.0.0 - 195.41.255.255 netname: DK-TELEDANMARK-961204 descr: Provider Local Registry descr: Tele Danmark Datacom country: DK admin-c: KBO1-RIPE tech-c: TB15-RIPE tech-c: CIN1-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 961204 source: RIPE route: 195.41.0.0/16 descr: Tele Danmark origin: AS3292 mnt-by: AS3292-MNT changed: Torben.Bajlum@datacom.dk400.dk 961204 source: RIPE According to my proposal the information below should NOT be available to everyone: inetnum: 195.41.47.0 - 195.41.47.255 netname: AARHUS-STIFTSTIDENDE-NET descr: Aarhus Stiftstidende descr: Olof Palmesalle 39 descr: 8200 Aarhus N country: DK admin-c: BR286-RIPE tech-c: BR286-RIPE changed: pha@datacom.dk400.dk 970418 source: RIPE
On Mon, 8 Sep 1997, TOB wrote:
At present the RIPE database is quite open, which means that it potentially can be used as a marketing database. My proposal is that only allocations are shown to everyone e.g the 195.41.0.0 /16 below. There is sufficient information to contact the provider in e.g hacker cases.
I use the RIPE DB a LOT to look up who people are. And that's most definately not for marketing purposes, but to solve problems of my customers, or remote ones. It's a far better idea to use DNS for marketing issues than the RIPE DB.
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 think the turn around time would be too long and it also makes it a lot more difficult tracking someone down if you want to block all connections from a specific allocation. It's most definately not all ISP's who replies to, even urgent, mail within a week.. if at all. -- Robert Martin-Legène (RM59), Network Manager (AS2109) main(){int a[2],b[2];pipe(a);pipe(b);if(fork()){dup2(a[0],0);dup2(b[1],1) ;}else{dup2(b[0],0);dup2(a[1],1);write(1,"R",1);}execlp("cat","cat",0);}
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
participants (3)
-
Andrew Crawford -
Robert Martin-Legene -
TOB