May 2003 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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

RE: [db-wg] Slash notation
by ipmaster＠bt.com 22 May '03

22 May '03

Shane, sounds good to me !! Thanx Dave Trickett BTnet -----Original Message----- From: Shane Kerr [mailto:shane@ripe.net] Sent: 21 May 2003 16:56 To: IPMASTER G Cc: db-wg(a)ripe.net Subject: Re: [db-wg] Slash notation On 2003-05-21 16:26:43 +0100, ipmaster(a)bt.com wrote: > Hi > > Quick question:-) > We used to be able to update (via email) the Database with new > inetnums using slash notation. Since the introduction of RPSL, this > facility has been lost, would it be possible to re-introduce it? > I can see the benefits of using the long hand version if I am > updating with a /27 and a /28, such as (*.*.*.64 - *.*.*.111). > But for Inetnums that fall on the bit boundary would not make sense > to enable the slash? > If I update a route object I can still use the slash notation. 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. 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. Explaination (for the curious): The reason that these types of modifications were avoided in the original design is because RPSL allows a number of formats that can make the changes difficult. For example: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0 + - # heck, you can even put a comment here 193.0.7.255 + # and at the end too Modifying this kind of attribute can be problematic, because the value is split across many lines, and has comments in the middle. However, with your suggestion it would be possible to do something like converting: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0/21 + # but still parsable! Into the following: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0 - 193.0.7.255 + # but still parsable! Since the CIDR-notation is "atomic", we don't have to worry about values split across lines or with comments inside. Note that comments and split lines in the primary attributes are very, very rare, but it is technically possible for any user that wishes to do so. -- Shane Kerr RIPE NCC

2 1

Slash notation
by ipmaster＠bt.com 21 May '03

21 May '03

Hi Quick question:-) We used to be able to update (via email) the Database with new inetnums using slash notation. Since the introduction of RPSL, this facility has been lost, would it be possible to re-introduce it? I can see the benefits of using the long hand version if I am updating with a /27 and a /28, such as (*.*.*.64 - *.*.*.111). But for Inetnums that fall on the bit boundary would not make sense to enable the slash? If I update a route object I can still use the slash notation. Dave Trickett BTnet

3 2

action item AP-42.3 - problems of multiple hashed passwords
by Larry J. Blunk 14 May '03

14 May '03

This is an update on AP-42.3 regarding identifying users of multiple hashed passwords (CRYPT-PW or MD5-CRYPT) in a mntner. Merit has implemented an option in it's web-based update form to include an "id" in the comment field of an "auth:" attribute. Additionally, the date and time of creation of the hashed password is included (should one want to keep track of the age of a particular password). Below is an example -- auth: CRYPT-PW Fa1QDrka0aOOM #Id:billg Created:20030514 09:42:45(UTC) As a further note, we have implemented (but not deployed) support for hashed password hiding. When this is deployed, the hash value of a CRYPT-PW will be replaced with the string "HIDDENCRYPTPW" when a mntner object is queried or mirrored. I'm not sure how much of this is of interest to the RIPE community (particularly with the PKI support on the horizon), but I thought I would throw it out for consideration. Regards, Larry Blunk Merit Network

1 0

Webcast RIPE 45 Announcement
by RIPE NCC Meeting Registration 13 May '03

13 May '03

Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to <ripecast(a)ripe.net>. Regards, RIPE Meeting Coordination Team

1 0