October 1997 - db-wg - mailman.ripe.net

Re: Who should do entries in RIPE database?
by Wilfried Woeber, UniVie/ACOnet 31 Oct '97

31 Oct '97

Folks, thanks for bringing this up for discussion! >The other point is to prevent the RIPE database from further pollution. >There should be some settings to guarantee this. What is your opinion: >should I post my suggestions just to 'lir-wg(a)ripe.net'and 'db-wg@ >ripe.net' or in addition also to 'local-ir(a)ripe.net'? I'll try to summarize from my point of view (both as DB-WG chair, Local-IR rep and of course as a dumb user :-) We have long since worked from the assumption that the "owner" of an object is responsible for it's on-going maintenance. We have always felt, that tigthening the rules too much would have a negative impact on all parties' willingness to register (at all) or to perform updates regularly. Then we introduced measures to protect *existing* objects by limiting the sources where updates (+ deletes :-) are accepted from (maintainer mechanism). This is particularly relevant for the IP Registry and for the Routing Registry. The next step has been protection of hierarchies in the object space with the mnt-lower mechanism, in particular for the Domain-Registry. Right now the Routing-WG and the NCC are working on the implementation of cross-notification for the routing registry. All of these mechanism can by now (or very soon) be used to ascertain a useful level of security and update control, including the referenced objects. This leaves us with two major weaknesses - or features: - A considerable percentage of the objects is not yet protected by the mechanisms which are readily available, and "tightening" the ropes requires a more careful approach by the various registries - leading to more work, in the end. In particular if we think about "owning" and protecting the person objects as referenced by data for the various registries.... - Nothing is there to prevent *any* party to put e.g. person objects into the DB. (And I certainly appreciate that myself!) Also, I suppose some other types of objects can be put into the DB without problems, unless they are in dircet conflict with one of the well-managed object spaces for a particular registry. This leaves us with a legacy of entries from the "Dark Ages" of DB deployment and with the on-going pollution of object space by way of "user error". This aspect is being addressed by the DB-Consistency Project. We work towards offering mechanisms to identify inconsistencies as described by a "catalogue of frequent problems" as well as by coming up with the logistics to repair these deficiencies. Again, to be successful, the registries shall be required to spend (considerable?) effort to participate in that activity. So what can be done on top of that to improve the situation? - We can offer improved mechaisms to deal with identification and authentication: this is on the agenda for the DB-Security Task Force. - We can try to improve the user interface. In particular to help the end-users to avoid the popular crimes like putting in just another person object as soon as there's a new reference: We (the AT-TLD administration) are in the process of designing and prototyping an interactive interface that should prevent most of these incidents. We're in contact with the NCC to determine the usefulness of that approach. Please stay tuned. - Last but not least we could think about "closing" the DB for public, that is anonymous, update or registration of objects. I think *that* would require *very* careful consideration, discussion, and establishing a broad consensus across (all of) the RIPE-WGs. I'd also expect considerable impact on activities like RIDE. But it is certainly not impossible to get that discussion going. Although (wearing no hat at all right now :-) I do not see a pressing need right now - taking into account that we have a set of mechanisms in the works to improve the situation. Comments and input welcome! Apologies for the lengthy speech... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------

1 0

Re: Who should do entries in RIPE database?
by Carol Orange 31 Oct '97

31 Oct '97

Dear Carsten, Yes indeed, the consistency problems in the RIPE database are well known and are even well documented in: ftp://ftp.ripe.net/ripe/dbase/info/consistency* and ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-26/pres/db-consist/ Our plans to deal with them are also documented in: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-27/pres/db/consistency/ We do plan to try to eliminate multiple objects pointing to the same person, as well as other clean ups of the person data. [As a side note, this project is now well underway.] We have not however discussed limiting the ability to enter data in the RIPE database, outside of the current and proposed authorization mechanisms. That would certainly be a significant change of course, and for that reason, I have cc'd the RIPE Database working group on this mail to get their feedback on this idea. Greetings, Carol Orange RIPE NCC In message <3456024C.70C28953(a)contrib.com>, Carsten Schiefner writes: >> As a result of a voluminous discussion with one of POPs I would like to >> point your interest on the following topic I am a little bit upset of: >> >> Almost everybody who knows about about the RIPE database schema (which >> is no secret at all!) can do entries just by sending a mail to >> 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, >> bad maintained or what-ever-you-want entries - especially person >> objects - without any fun in grepping through them and selecting the >> right one to create a new object. Example: >> >> There are four(!) entries for the entity "Joerg Schmidt" of "ZWF >> Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, >> JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! >> >> My idea is that we should discuss future restrictions on the possibility >> for everybody to put entries in the RIPE database, maybe by setting up >> and maintaing access lists for every LIR. >> >> For me this database is a central tool in my daily work and I am very >> interested in keeping quality and reliability of stored data as high >> as possible. >> >> Kind regards, >> >> Carsten Schiefner >> -- >> >> Carsten Schiefner mailto:schiefner@contrib.com >> TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com >> Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 >> ======================================================================

2 1

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Dale Amon as Operator <root(a)starbase1.gpl.net> Date: Thu, 30 Oct 97 11:21:59 GMT To: Carsten Schiefner <schiefne(a)contrib.com> Subject: Re: Who should do entries in RIPE database? Cc: local-ir(a)ripe.net Reply-To: amon(a)galileo.gpl.com References: <3456024C.70C28953(a)contrib.com> > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > Why? > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > Please let's not add more things to remember. The job of admin people at ISP's is rough enough as it is. I'd personally rather see every possible effort made to decrease work loads on everyone's part, and to decrease the number of things that need to be remembered. I applaud the improvements made in the RIPE database over the last 5 years. The "smarts" in the process are a real help for people who are trying to do so many things at once that errors are inevitable. > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. It is also a central tool in my work and I am more interested in simplicity of the process of working with my own data than I am in simplicity of others using my data. So long as my routing and DNS work, I could care less if someone has 500 entries under their name. ------- End of Forwarded Message

1 0

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Christian Kratzer <ck(a)toplink.net> Message-Id: <199710301109.MAA17929(a)toplink1.toplink.net> Subject: Re: Who should do entries in RIPE database? To: schiefne(a)contrib.com (Carsten Schiefner) Date: Thu, 30 Oct 1997 12:09:58 +0100 (MET) Cc: local-ir(a)ripe.net In-Reply-To: <3456024C.70C28953(a)contrib.com> from "Carsten Schiefner" at Oct 28, 97 04:18:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Content-Length: 1555 Hi > As a result of a voluminous discussion with one of POPs I would like to > point your interest on the following topic I am a little bit upset of: > > Almost everybody who knows about about the RIPE database schema (which > is no secret at all!) can do entries just by sending a mail to > 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, > bad maintained or what-ever-you-want entries - especially person > objects - without any fun in grepping through them and selecting the > right one to create a new object. Example: > > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. it would propably be sufficient to require a passphrase for auto-dbm(a)ripe.net so only regisitiers with registered passwords could submit entries or change records. This would definetely keep the "internet experts" from mucking around in the database.d Greetings Christian - -- TopLink GbR, Internet Services info(a)toplink.net Christian Kratzer http://www.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here! ------- End of Forwarded Message

1 0

RIPE Database software release 2.1
by Chris Fletcher 27 Oct '97

27 Oct '97

RIPE Database software Version 2.1 is now available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.1.tar.gz The release notes are included below. There a some new features including a new installation procedure and conversion to perl5. Please let us know if you have problems. Replies to <ripe-dbm(a)ripe.net>. Regards, Chris Fletcher - RIPE NCC RELEASE NOTES for RIPE Database 2.1 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi2.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES When an update sends an acknowledgement and a notification to the same mail address one or the other can be suppressed see SUPPRESSMESS in the config file. New concise format for acknowledgements and notifications. '-v' provides detailed object descriptions. Re-implemented Makefiles and package configuration for ease of use. Includes an 'uninstall' target to carefully remove the executable and libraries when upgrading. Now two help files, one about the whois interface delivered by whois and one about the mail interface delivered by mail. Notifications are sent when an object is created with a notify: attrib. Whole package runs under perl5.004 with DB_File interface to Berkley db. Perl5 hides a lot of platform specific things from scripts so various configuration options have been made obsolete and removed. DB_File allows you to increase the size of the in memory db file cache which greatly improves indexing performance. see DBCACHESIZE We have not tried it with other DBM packages but it should not be hard to change if you want to use GDBM_File. This could become a configuration option (or maybe use AnyDBM_File) if there is demand for it. Changed syntax of 'changed:' & 'withdrawn:' to allow a 4 digits in the year part of the date (8 digits in total rather than 6). Automatically added dates are 8 digits. Existing 6 digit date fields are left unchanged. BUG FIXES added word boundary matches to subject line parsing now matches 'new object' and not 'My Apple Newton'. added 'i' to regexp check of MAIL-FROM so is not case-sensitive changed code to match comments in ripedb.config won't log incoming serial updates to files if SERIALINCOMINGDIR is not defined. MISC Added copyright message to all source files to better assert our rights but licence has not changed from previous versions. I have had problems with bitwise operations on the large integers used to represent IP addresses. With some versions of perl5 a bitwise '&' returns a signed result. This causes classless lookups to fail. See comments about iprightzeromask in misc.pl. It seems to work with perl5.00401 Changes to ripedb.config The following values have been removed... HELP (replaced by WHOISHELP & AUTODBMHELP) RENICECMD (optional - will use setpriority(2) if not set) The following values have been added... WHOISHELP AUTODBMHELP ATTDESC OBJDESC DBCACHESIZE SUCCESSTXT HELPHEADER FAILURETXT

1 0

Re: some problem in syntax.pl
by Steven Bakker 20 Oct '97

20 Oct '97

>>>>> On Sat, 18 Oct 1997, "HH" == Hwang Hyojung wrote: HH> why do you eval check ? Isn't this necessary ? Rather, I think, HH> $regex is checked if it is valid email address. How do you think HH> about it ? If it is necessary, please explain why this is needed . HH> Thanks in advance !! Please read RIPE-157, section 2.3.3., Authorization Schemes (shouldn't that be "Authorisation", Ambrose? :-). There is a section labeled, `The "MAIL-FROM" scheme:', which explains that the MAIL-FROM value in the "mntner" object is treated as a regular expression, against which From:- headers will be matched. So, yes the "eval" is necessary to make sure people submit a valid regex in their "mntner" objects. While we are on the subject, RIPE-157 mentions that the regex should comply to the rules in "POSIX 1003.2 section 2.8." Not having read that document, I wonder if the POSIX syntax and Perl are identical. "syntax.pl" checks whether the regex is Perl-compliant. For example, does '(abc)' mean "the literal string '(abc)'", or (a-la Perl), "the subpattern 'abc'"? Cheers, Steven

1 0

some problem in syntax.pl
by Hwang Hyojung 18 Oct '97

18 Oct '97

Hi, I am Hyojung Hwang and working for Korea Telecom. I am using ripe dbase software. I found some problem or starnge things in this code. In syntax.pl, checking 'auth' attribute, --- elsif ($authstr[0] eq "MAIL-FROM") { local($regex) = $value; $regex =~ s/^\s*MAIL\-FROM\s*//; eval "/$regex/;"; if ($@) { return $O_ERROR, "\"$regex\" is not a legal regular expression"; } else { return $O_OK; } } --- why do you eval check ? Isn't this necessary ? Rather, I think, $regex is checked if it is valid email address. How do you think about it ? If it is necessary, please explain why this is needed . Thanks in advance !! -- * _ _ ==GD@: 56@L0m Hq8A@: 1$1b@L4Y. ||_|| ||_| Hwang, Hyojung / jung(a)jean.kotel.co.kr / 82-2-526-5235 |_| _|_ Internet Team / Multimedia Laboratory / KT R&D Group |_| 137-792, 17 Umyun-Dong, Seocho-Gu, Seoul, Korea

1 0

Slow update processing.
by RIPE Database Administration 14 Oct '97

14 Oct '97

Dear Colleagues, This afternoon, two large update messages were sent to <auto-dbm(a)ripe.net>. They were sent very close together in time. This has created a queue which is longer than normal. We expect this queue to be at its normal size soon. We thank you for your patience. You are not required to send in your update message again. We ask that you think of other users when you send in long update messages; please send them in outside working, "office" times. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

auto-dbm
by Helen Dagerus 14 Oct '97

14 Oct '97

Is there something wrong with the database auto-dbm? Kind Regards Helen Dagerus Tele2/SwipNet

1 1

Database Updates.
by RIPE Database Administration 02 Oct '97

02 Oct '97

Dear Colleagues, There is a queue of Database updates. This is because of a problem which we fixed this morning. We anticipate that the queue will be processed by 1300 UTC today. Thank you for your patience. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0