June 1998 - 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

Changes in the "changed" field
by Joao Luis Silva Damas 25 Jun '98

25 Jun '98

Dear all, There have been concerns lately about e-mail addresses in the "changed" fields being used to send unsolicited e-mail messages. Please review this discussions in the mailing archives. Archives for the RIPE mailing lists are available at http://www/info/maillists.html After deliberations in the db-wg mailing list, the RIPE NCC suggests the implementation of the following changes: - By default changed fields won't be shown in queries. - These fields can be retrieved using a query option (whois -c). - These fields will not be compared against incoming data when deleting the object. The RIPE NCC would appreciate comments on the mentioned changes before implementation begins. The comment period will be a week since the posting of this message. Please direct your comments directly to the RIPE NCC using the ripe-dbm(a)ripe.net mailbox. The changes will be implemented in the next release of the RIPE DB code, due July 15th, 1998. Best regards, Joao Damas RIPE DB group RIPE NCC

6 5

(no subject)
by Sam J. H. Hamilton 22 Jun '98

22 Jun '98

1 0

Re: how to proceed with changed:
by Wilfried Woeber, UniVie/ACOnet 10 Jun '98

10 Jun '98

Folks, ( for a moment wearing my hat as RIPE-DB chair ) I'm asking all of you to try to have an educated discussion of DB problems, proposals for changes and proposed solutions. Discussions about history, the relative merits(?) of spam and/or legal aspects is - I think - outside the scope of this mailing list. Please move to the appropriate fora to tackle these issues. Thank you very much for listening. Regards, Wilfried Woeber -------------------------------------------------------------------------- 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 --------------------------------------------------------------------------

1 0

Re: how to proceed with changed:
by kissg＠sztaki.hu 10 Jun '98

10 Jun '98

James Adridge wrote: > If people change jobs then it should be possible to perform an inverse query > on the changed field in the same way as the admin-c, tech-c, etc. to permit > updating of all affected records. I think active ripe-ops are also unhappy if spammed newbies send them tons of complaining mails. Remember this philosophy: | For legal reasons, anyone and everyone that is related to an IP Address | or related higher domains or IP routes are included in the anti-spam | message, that way noone can say later, they didn't know or weren't | notified about the law. These peoples doesn't know and doesn't want to know what is the difference between changed and admin-c fields. They just see Yet Another E-mail Address To Born. Which of you wants to be "anyone and everyone"? I definitely not. A new idea: Every "changed" field should contain <president(a)whitehouse.gov>. So the Secret Service or the FBI will explain politely all of these newbies, that Lenin was right when he said: "To learn, to learn, to learn" (before writing) :-) Regards Gabor

2 1

how to proceed with changed:
by Daniel Karrenberg 09 Jun '98

09 Jun '98

Let my try to summarise the discussion: 1) changed has a fuzzy definition, a more concise audit trail attribute should replace it. A concrete proposal is needed. David has already thought about this. Want to write it up. Do *not* call it changed:! 2) I porposed to exclude changed: from answers to normal queries. Present the changed attribute only when the query contains a special flag (like -c). The only serious problem with the proposal I have read so far is the comparison for deleting an object. This could be changed to exclude changed: attributes. Anything I am missing? Daniel

3 4

Re: "changed" field should be deleted
by Havard.Eidnes＠runit.sintef.no 09 Jun '98

09 Jun '98

> There is a general problem with publicly available email contact > information. I would prefer to solve the general problem. I'd say that if you are out to generalize, there is a general problem of SPAM. Why not solve that instead? 1/2 :-) Seriously, I think that effectively removing contact information from the database is much too similar to sawing off your foot at the knee because you have an itch in one of your toes. I mean, how long will it take before all and everyone needing (out of policy) or wanting to have their contact information publically available to install an auto-filter which will toss messages with "unknown" digital signatures ("of *any* kind"?)??? I think it'll be easier and quicker to deal with the SPAM problem itself before we get there. Besides, the contact information also currently serves as a means for anyone to get in touch with the domain holder or the technical administrator of the domain, in conjunction with e.g. security- related events (yes, I know, it's maybe not fully reliable, but what else is there?), and those messages, even if they were digitally signed, would probably come from an "unknown" key-holder. In all, I have serious misgivings about this general idea of removing contact information from the database. - Håvard

2 1

"changed" field should be deleted
by kissg＠sztaki.hu 09 Jun '98

09 Jun '98

Dear folks, Nowadays I can see a new style of anti-spam fight. If the victim gets some junk mail, (s)he retrieves all database objects (including *rt) relative to ALL hosts, domains, and IP addresses that can be found in the mail header, and s(he) send complaining mails to ALL the fifty e-mail addresses found in the database objects (including the *ch field). :-( So these uneducated lamers multiply the amount of spam and harras a dozen of peoples who are not responsible for the original junk mail and the spam relays. The lamers cannot diffrentiate the "responsible persons" and those who maintain the database records itselves. My first radical suggestion is: Let's delete the *ch field from the database objects. However I know that there should be some info about the history of records. a few raw ideas: - modified database software that hides the *ch field. *ch's could be retrieved with some extra efforts only - some coded ID instead of e-mail address. Ordinary peoples couldn't decode it but authorized ripe-ops could. (E.g. via WWW or e-mail) This info shouldn't be public. What is your opinion? (Personally I've changed my jobs years ago but my e-mail address can be found in hundreds of *ch fields. So I hate the anti-spam spam as well than the spam itself.) Regards Gabor

8 14

Re: "changed" field should be deleted
by kissg＠sztaki.hu 08 Jun '98

08 Jun '98

> > "Other users" are not really interested in the real e-mail address > > of changer. This field is needed only by administrators who want to > > delete the object because they have to send back the exact copy of > > the record. > > "Other users" are at least interested in the latest modification date > and the address of someone to report problems to. When I find wrong > information (mostly bouncing email addresses) in an entry I usually > send a note to the address in the last "changed" line. This means you are not "other user". :-) Anybody who knows what the what is the changed field for is a guru. Gurus can put an extra switch in the whois query to retrieve the real list of changers. regards Gabor

1 0

Re: "changed" field should be deleted
by Gerald Andrew Winters 05 Jun '98

05 Jun '98

from Michael van Elst <mlelstv(a)xlink.net> Hi, > > This would obviously help the registries but other users of the RIPE-DB > > might be left out by this solution. > > "Other users" are not really interested in the real e-mail address > of changer. This field is needed only by administrators who want to > delete the object because they have to send back the exact copy of > the record. well, that's a kind of broad statement comparable to the "no user would need more than 640k". Won't you think ? For me the changed records help to track down the person who modified the record and who could possibly tell what was changed and why it was changed. Of course you cannot trust the records, but it gives strong hints. from gerald(a)merit.edu In my mind it is tough to make the argument to keep email addresses in the changed field because it helps you know the person to make the last change. You can specify the "mnt-nfy:" attribute in the maintainer or "notify:" attribute in the object to have an email message sent which give the email header of the person who made the udpate. You always have a problem in situations like this when you want to make a change to the database registry to something that has been around a long time. There are always going to be users who don't want to change things for whatever reason. eg, I still have people tell me they use the old ANS "advisory:" field which I think has been obsoleted for quite some time now. So even a proposal to get rid of the "advisory:" field would meet with some resistence. My $0.02, the "changed:" field as it is is worse than useless. The information that goes in it right now belongs either in a "descr:" field if someone chooses or not in the db at all. And there is a legitimate privacy issue which needs to be addressed. I am in favor of keeping the "changed:" field. I feel it should contain the UTC machine generated time stamp of the last update and that's it. We would know the last update and I also feel we (someday) need a mechanism for dealing with legacy objects, ie, objects that have been abandoned. A *real* time stamp along with real routing announcement information would go a long way into dealing with this problem. --jerry

1 0