- db-wg - mailman.ripe.net

whois output and the "changed" line.
by RIPE Database Administration 11 Sep '98

11 Sep '98

Dear Colleagues, Recently, the output of our whois server was modified; the "changed" information is not shown by default. To see it, the new "-c" flag must be used. This requires using the new RIPE whois client. The "changed" information was removed from the default output of whois after a discussion on the mailing list of the RIPE Database Working Group. This discussion was about the funtionality of the "changed" line. A long-term replacement for it (i.e. timestamping of updates) is planned. However, there is the possibility that the existing "changed" lines can be accidently deleted from objects. When users want to update an object, they do a whois look-up and re-direct the output into a temporary file. Then, they edit the file and send it to <auto-dbm(a)ripe.net>. Thus, before the output of the whois server was modified, the update contained all the previous changed fields. Now, unless the user does "whois -c", the "changed" attributes are not shown. But when users want to update an object, they re-direct a whois look-up into a file, edit it and then send it to the database. However, this time, the "changed" lines are missing and the updated version of the object does not contain the previous "changed" lines. This behavior is what would have happened previously if you had sent an update to the db and had deliberately omitted the changed lines. (BTW, if you send an update to the db which only has a new "changed" attribute or has all the old "changed" attributes replaced with a new one, a NOOP is the result. The object in the db is not changed). If all the original "changed" information in an inetnum object is not retained, there may be a delay in getting reverse delegation for the associated address space. This is because <auto-inaddr(a)ripe.net> checks the date when the assignment was originally made and compares it to the assignment window which the local registry had on that date. Thus, the request for reverse delegation is processed manually. So, to keep all the "changed" attributes, do 'whois -c' when you are making a copy of the object before updating it. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Re: Cc: in <auto-dbm> replies
by kissg＠sztaki.hu 11 Sep '98

11 Sep '98

> > I think the database should send any outgoing mails > > with sender address <nobody(a)no.where.ripe.net> or similar Dear Carsten, > come on, you're kidding, aren't you? This would mean to expand > Usenet's bad habits to RIPE email answers. That doesn't seem to > be a really good idea... I just say that *automatic* aswers should be blocked. However I don't think to hide the real sender as spammers do. Any human intelligence can find out easily where the mail came from if the RFC822 header contains a Sender: or X-This-Mail-Really-Came-From: ;-) line. So this header looks absolute correct for me: To: <as required> Cc: <as proposed> From: bit-bucket(a)ripe.net (Do not reply this address) Sender: ripe-db(a)ripe.net (RIPE database engine) X-Comment: This is an acknowledgement, not intended to be replied. Regards Gabor

1 0

Re: Cc: in <auto-dbm> replies
by kissg＠sztaki.hu 11 Sep '98

11 Sep '98

> The suggestion and motivation is excellent, but there are nasty side > effects in practice: > > Including the Cc: field is a nice way to create mailloops. > When the 'Cc:' address would be used too, there is no way for the > database to break the loop since the 'Cc:' address is set by the user > and can possibly contain the automatic mail address of the db and/or > a (local) alias to the db. Hi, David! I think the database should send any outgoing mails with sender address <nobody(a)no.where.ripe.net> or similar nonexistent address. This would break any mailing loop. This is acceptable for humanoid recipients too because generally they don't want to reply the notifications and acknowledgements. Regards Gabor

3 2

Re: Cc: in <auto-dbm> replies
by Gunnar Lindberg 11 Sep '98

11 Sep '98

Actually, if you're already in the "parse 822 addresses" business (Reply-To: is one of them - possibly one of the more controversial) then one would assume you've been through most of the "who am i" problem already. Otherwise I'd be happy to share my copy of UCBMail, 1985, with you; many years later it has actually learned that I am <lindberg(a)cdg.chalmers.se>, not bad, right :-). Sorry, but I couldn't resist :-). Point taken, workaround noted, you <auto-dbm> folks probably have enough things to do anyway. Gunnar >From: johnpc(a)xs4all.net >Date: Thu, 10 Sep 1998 23:57:20 +0200 >To: David Kessens <davidk(a)ISI.EDU>, > Gunnar Lindberg <lindberg(a)cdg.chalmers.se> >Cc: db-wg(a)ripe.net >Message-ID: <19980910235720.D28191(a)xs3.xs4all.nl> >Subject: Re: Cc: in <auto-dbm> replies >On Thu, Sep 10, 1998 at 06:18:17PM +0000, David Kessens wrote: >> > Folks, I'm not on this list but <ripe-dbm(a)ripe.net> suggested I send >> > the idea to you. Right now I hope there is no spam-filter :-). >> > >> > My suggestion: >> > >> > Could you please make <auto-dbm(a)ripe.net> keep the Cc: list and >> > return responses to everybody on it (as well as everybody on To:). >> >> Currently, The 'From:' field (note: not the 'To:' field) is used which >> is a field that is set by the user upon arrival of the update message >> and set by the db after sending the message as the human mail box of >> the database. >I've just tested, and it seems the Reply-To: field is used if present. >So if you want to get the ripe-dbm to reply not only to you, but to >your coworkers as well, simply send the mails using: >Reply-To: you(a)w.ork.com, orkers(a)cow.ork.com > >> When the 'Cc:' address would be used too, there is no way for the >> database to break the loop since the 'Cc:' address is set by the user >> and can possibly contain the automatic mail address of the db and/or >> a (local) alias to the db. >You could break the loop by putting all the Cc: addresses in the To: >field, which isn't examined by the db. Well, unless seriously broken >mailers but the addresses back in the From: or the Cc: lines. But >then there's... > >> With the volume of mail that RIPE receives, broken mail systems and >> user errors like this do happen and would result in an unstable db >> system which is not very desirable. >You're RIPE, right? Just reclaim their IP space and add it to RFC1918/RFC1597 >:) (oh, wait, this ISN'T bofh.general? :) >-- >#! ##### Jan-Pieter Cornet ##### <johnpc(a)xs4all.net> ##### perl >++$_;$!=$_+++$_;($:,$,,$/,$*)=$!=~/.(.)...(.)(.).(.)/;$!=$_+$_; >($(a),$\,$~)=$!=~/(.)(.).(.)/; $_="$,$/$:"; $@++; $~="$~$_";($_)= >\$$=~/\((.)/;$|=++$_;$_++;$|++;$~="$~ $@$:";`$~$/$\$*$, $|>&$_`

1 0

Cc: in <auto-dbm> replies
by Gunnar Lindberg 10 Sep '98

10 Sep '98

Folks, I'm not on this list but <ripe-dbm(a)ripe.net> suggested I send the idea to you. Right now I hope there is no spam-filter :-). My suggestion: Could you please make <auto-dbm(a)ripe.net> keep the Cc: list and return responses to everybody on it (as well as everybody on To:). Motivation: Sending a request with a Cc: is usually because you want other people to be aware of what happens. Since <auto-dbm(a)ripe.net> doesn't keep Cc: that doesn't work and you have to forward the response manually. Now, of course *I* NEVER forget such a thing, but others do... :-). Gunnar Lindberg

3 2

1. draft, proposed agenda for DB-WG Mtg @ Edinburgh
by Wilfried Woeber, UniVie/ACOnet 27 Aug '98

27 Aug '98

Attached plese find the 1st draft of the proposed agenda for the DB-WG meeting during RIPE#31 in Edinburgh. As always, comments and suggestions more than welcome! In particular, please get in touch with me asap in case you want to get a slot for a presentation! Looking forward to see many of you in Edinburgh! Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 -------------------------------------------------------------------------- Proposed Agenda for the Database Working Group Meeting RIPE-31, September 1998, Edinburgh 1. Draft, August 27, 1998 A. Administrative stuff (Wilfried Woeber, chair, 5min) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statitics, performance, changes - most recent mod.s: cross-notification handling of changed: referral - RPSL status, usage - mirror systems at other registries' sites C. RIPE DB, software development status (RIPE NCC) - done, being worked on, in the queue D. DB SW Re-implementation (RIPE NCC) - status, milestones/roadmap, resources required/available E. I-D draft-zsako-ripe-dbsec-pgp-authent-00 (Janos ? [Joao]) F. PGP deployment in the RIPE DB (RIPE NCC) - licenses, support G. ripe-157++ - who, how & when H. I-D draft-ietf-rps-auth-01, -rps-dist-?? (Cengiz ?) - RIPE region requirements/comments X. Chicago IETF report(s) ? Y. Input from other WGs - t.b.d. Z. AOB WW, 28-AUG-1998 00:19:01

1 0

New beta version of the RIPE DB
by Joao Luis Silva Damas 21 Aug '98

21 Aug '98

Dear all, we are happy to announce a new beta version of the RIPE DB. The major change in this release is the introduction of support for an additional authentication method, which in this case uses PGP. The previous authentication methods were NONE, MAIL-FROM and CRYPTPW. The new method is called PGPKEY and is described in draft-zsako-ripe-dbsec-pgp-authent-00.txt internet-draft (available at the usual places, eg. ftp.ripe.net). This draft reflects the work done by the RIPE Database Security Task Force up to this moment. The code is not available for download at this moment. There is a setup so users can experiment with it. * Queries can be done using a whois client pointed to the beta database at beta-whois.ripe.net port 43. * Updates can be sent to auto-beta(a)ripe.net The current setup contains only maintainer objects (a copy of the real ones as of yesterday) which are necessary to experiment. The draft is not yet fully implemented in this beta release (some checks are not done) but it allows operational experience. The code is beta quality and may have bugs. If you find any, please report them to ripe-dbm(a)ripe.net. The messages will however not be answered as fast as normal ripe-dbm. We will issue a new beta release soon and a final release is planned before RIPE31. Details about licensing PGP (free) for use with the RIPE Database will also be made public soon. If you have any questions, don't hesitate to ask. Happy testing, Joao Damas RIPE NCC

1 0

IRRd source code release
by Gerald Andrew Winters 17 Aug '98

17 Aug '98

For those who are interested we are announcing our first IRRd source code release which can be found at the following location: http://www.merit.edu/radb/irrd We will be updating the source code periodically with bug fixes, feature enhancements, etc... Each new IRRd release will be tagged with the version number to distinguish it from prior releases. The current code release is version 1.0. We wish to thank those people who have already begun to test IRRd and we continue to solicit users who feel they might be interested in the IRRd software package. -- IRRd Development Team <irrd-support(a)merit.edu>

1 0

"Changed:" field
by Andrey Petukhov 17 Aug '98

17 Aug '98

Dear Colleagues, I'd like to propose new behavior of the "Changed:" field of the database objects. It would be more convenient if database (or its front-end robot, processing requests from mail messages) sets value of the "changed:" field itself using "From:" field of the mail header/envelope. Database could contain "changed:" information in three modes depending of user needs: 1. Only one record, reflecting last change. 2. Two records, reflecting event of the creation of the object and "last changed" event. 3. Full history of the changes. The first record means "created", and next records reflect every change, sorted by date. The mode of the "Changed:" field can be described in the "mntner" object and is applied to all objects controlled by this mntner. The default behavior of this field applied to objects without mntner. In all cases the field(s) "changed:" have form "Changed: <e-address> <date>", as it is now, but <e-address> is retrieved from mail header/envelope with appropriate authorization checks (it is being done now), <date> is current date of the modification. There is no need to store changes itselves, that is subsequent versions of the object are not stored. Best Regards, -- Andrey Petukhov (AP9-RIPE) Phone: +7 095 705 9229 Systems Engineer Fax: +7 095 929 9363 Global One Russia (RoSprint) Mailto:pooh@ipnms.rosprint.net

1 0

Performance of the RIPE Database
by RIPE Database Administration 17 Aug '98

17 Aug '98

Dear Colleagues, There is normally a delay of 10 minutes between an update being processed and it being visible using the whois service. We are aware that this delay has increased and we are taking action now to maintain the delay at normal levels. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0