- db-wg - mailman.ripe.net

Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Tim Christensen 11 Jul '03

11 Jul '03

> when you say that the trend among the other RIRs is to go for X.509 > certificates, could you please elaborate on what they are > doing and how > far they are? Greetings all, Currently, ARIN is working toward deployment of X.509 as a strong authentication method for securing email template submissions. We expect implementation to occur later this year. After X.509 deployment for templates, ARIN will explore both the expansion of X.509 into other methods of interfacing with ARIN, as well as other strong authentication mechanisms. Regards, Tim Christensen Database Administrator American Registry for Internet Numbers (ARIN) (703) 227 9876

1 0

X-NCC-RegID : cm.intelcam deleting objects
by Local Internet Register 30 Jun '03

30 Jun '03

Date: Wed, 25 Jun 2003 14:09:01 -0100 (GMT) From: Local Internet Register <registry(a)intelcam.cm> Subject: X-NCC-RegID : cm.intelcam deleting objects To: lir-help(a)ripe.net Cc: registry(a)intelcam.cm MIME-Version: 1.0 Content-MD5: ZpkYzRVbqYcHSqym9KzPtA== Hello! This is LIR Cameroon. We would like to know how to delete the following objects from the RIPE database. Best regards TONYE Antoine Joseph Junior inetnum: 195.24.204.128 - 195.24.205.63 netname: NEWTECH descr: Internet Service Provider descr: BP 6269 Yaounde Cameroon country: CM admin-c: EAA11-RIPE tech-c: DM5338-RIPE rev-srv: ns.ripe.net rev-srv: fw.itu.ch rev-srv: sanaga.camnet.cm rev-srv: lom.camnet.cm status: Assigned PA notify: registry(a)intelcam.cm mnt-by: RIPE-NCC-NONE-MNT change: registry(a)intelcam.cm 20000412 source: RIPE person: David MABVOURI address: BP 6269 Yaounde Cameroon phone: +237 22 19 82 fax-no: +237 22 19 81 e-mail: david.mabvouri(a)wipo.int nic-hdl: DM5338-RIPE notify: registry(a)intelcam.cm changed: registry(a)intelcam.cm 20000411 source: RIPE

2 1

New "status" tag of REVOKED requested
by Hank Nussbacher 25 Jun '03

25 Jun '03

The following was posted to APNIC without much comment. Since RIPErs are more outspoken, I'd like to raise it here as a possible idea for implementation. >I am part of a volunteer team along with Barry Greene and Terry Baranski >that contact Internet users (ISPs and corporates) when they start >announcing something wrong on the Internet. Recently, Geoff Huston updated >his CIDR report - http://bgp.potaroo.net/cidr/#Bogons and up popped a >number of APNIC customers that were announcing prefixes that were not >allocated in APNIC. > >Turns out that the customers membership was "closed" and APNIC tried >contacting them with no success. APNIC waits about 90-120 days before >closing a member for non-payment. APNIC then sends an email informing the >upstream to stop announcing the IP range that has been reclaimed from the >closed member. Then they remove all the database objects which are related >to this organisation from the WHOIS database. After a one year period, >APNIC will start to reallocate/reassign that particular IP range to other >organisations. > >The problem is that the upstream or even the customer themselves continue >to use the prefix and announce it to the Internet, thereby falling into the >Bogon category. > >I think 90-120 days is too little before removing the inetnum object. I >also think that a better a tactic would be to add a "remarks" to the >inetnum or perhaps create a new "status" tag such as REVOKED. I also think >such a policy should be uniform between RIRs. > >Comments? -Hank

2 1

Hi to the group
by A. Hakan ASKAR 05 Jun '03

05 Jun '03

Dear all ! We are an ISP operating in Turkey called Gediknet. We got some problems about managing our IP blocks. As Gediknet A.S. these ip blocks ( 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the whois db you can see that these ip's are mnt-by your RIPE. We are trying to get an AS Number but as you can imagine we are not the mnt !. To correct this problem, what can we do ? Regards ; A. Hakan ASKAR Gediknet A.S. Manager

1 0

Re: Improvements to database update software
by DB-News 04 Jun '03

04 Jun '03

Dear Colleagues, [apologies for duplicate messages] This is to announce that the transition period for the introduction of new database update software is over. This means that the mail boxes auto-dbm-old(a)ripe.net and auto-dbm-new(a)ripe.net are not available any more and all update messages to auto-dbm(a)ripe.net will be processed by the new database update software. Best regards, -- Engin Gunduz RIPE NCC Database Group -- DB News wrote 23 Apr 2003: > > [apologies for duplicate messages] > > Dear Colleagues, > > The Database Group at the RIPE NCC has been working on restructuring > the dbupdate program. This is the part of the RIPE Whois server that > processes update requests from users. > > The main goal has been to improve the acknowledgement messages that > users receive from the RIPE Whois Database and provide clearer error > reporting and authorisation information. We have also been able to > make the software easier to maintain and modify. This will reduce the > time spent fixing bugs and adding new features. > > Details may be found here: > > http://www.ripe.net/db/dbupdate/ > > A page further explaining the new acknowledgements can be found here: > > http://www.ripe.net/db/dbupdate/acknowledgments.html > > The new dbupdate messages have a different format. Therefore a phased > approach to introducing the new server has been taken. For a period we > will use the new dbupdate in parallel with the old one. This will > allow people using automated tools time to update their software. > > PRE-MIGRATION > Before the new dbupdate was available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > DAY-X, Wednesday, 23 April, 2003 > The new dbupdate is available but must be requested specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Y, Wednesday, 7 May, 2003 > The new dbupdate is the default but the old dbupdate may be requested > specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 > The old dbupdate is no longer available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > > Best regards, > > -- > Shane Kerr > Database Group > RIPE NCC

1 0

changed-lines in objects.
by Fredrik Widell 26 May '03

26 May '03

Hi db-wg, I have a suggestion which maybe is good or bad :) A thought occured to me (as I for the xxxx'th time was accused of hacking somebody who has a firewall). The changed-line in every object simply refers to a mail-adress and a timestamp. Whould'nt it be more accurate to have a nic-hdl instead of just a mailadress there? managers of objects move, and mailadresses gets obsolete, and the only thing they are used for is to send abuse-matters, which of course are the wrong recipient in 99.9% of the cases, but if there was a nic-hdl, one could give information via that nic-hdl on how to get in contact with 'good' recipients, or the users would have to actually think and maybe realize that the other names that occur in an answer from ripe-db possibly could be the right recipients for abuse-matters. an example, instead of this: inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: ber(a)sunet.se 19940420 changed: fredrik(a)sunet.se 19990211 changed: fredrik(a)sunet.se 19991105 source: RIPE there would be inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: BE10 19940420 changed: FW526-RIPE 19990211 changed: FW526-RIPE 19991105 source: RIPE Comments are welcome. -- Best regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------

4 4

Problems with route object update
by Marcus.Ruchti＠colt.de 22 May '03

22 May '03

Hi all, I've recognized that we have massive problems in the last weeks with RIPE database updates by other ISP's. e.g. a new customer wants that we will announce a PI network used by him but it is maintained by another LIR. I've asked for creating a route object with our maintainer several times without success. I think all this happens with intention to constrain the business activity of the competitor ! Is there a possibility to insert the RIPE-NONE Maintainer in the whole PI blocks (e.g. /16). In this step I won't mention the names of those ISP's... regards, Marcus Ruchti COLT Telecom GmbH

1 0

Re: [db-wg] Slash notation
by Janos Zsako 22 May '03

22 May '03

> From db-wg-admin(a)ripe.net Thu May 22 14:59:10 2003 Dear all, > > ... Just another suggestion (from what I experienced in my environment): > > > >Would it be possible to treat/convert > > > >inetnum: 193.0.0.221 > > > >to > > > >inetnum: 193.0.0.221 - 193.0.0.221 > > > >(the 'single host') > >? > > is there a possibilty for ambiguity? I guess there is, especially if the last element is 0 (e.g. 194.152.133.0, which probably can be confused with 194.152.133.0/24). It cannot be ambiguous, however, if the last element of the dotted quad is an odd number. > Probably not if we have all 4 fields of the dotted quad included. > > Maybe we c/should require 193.0.0.221/32 here to be on the safe side? I would prefer this latter (i.e. requiring the /32). Janos

2 1

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Ulrich, Shane, > ... Just another suggestion (from what I experienced in my environment): > >Would it be possible to treat/convert > >inetnum: 193.0.0.221 > >to > >inetnum: 193.0.0.221 - 193.0.0.221 > >(the 'single host') >? is there a possibilty for ambiguity? Probably not if we have all 4 fields of the dotted quad included. Maybe we c/should require 193.0.0.221/32 here to be on the safe side? Wilfried.

1 0

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Shane! >Short answer: > >When version 3 of the Database software was designed, one of the >principles used was to not change user data as it was submitted. >This included the transformation you defined. Still a reasonable guideline, I'd say.... >The easiest solution would be to convert the CIDR to ranges, as you >suggest, so: > >inetnum: 193.0.0.0/20 > >Would become: > >***Warning: inetnum '193.0.0.0/20' converted to '193.0.0.0 - 193.0.7.255' > >inetnum: 193.0.0.0 - 193.0.7.255 > . > . > . > >If this makes sense, we'll include this change shortly. Yes, please! [ and still: yes, please - even after reading your in-depth explanation... ] Regards, Wilfried.

1 0