June 1998 - db-wg - mailman.ripe.net

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

17 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 06 Jun '98

06 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

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

06 Jun '98

> > Then the whole db software could be modified in such a way that > > it reponses just a fake line (changed: you-are(a)not.interested.in-it 990101) > > unless the query contains a "-C almost_secret_password_here" option. > > The so called "password" might be retrieved by e-mail > > from the RIPE NCC. > > 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. Regards Gabor

3 2

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

05 Jun '98

> > I agree that this needs attention. > > The whole changed: functionality should be reviewed. > > > > I agree that a short term measure could be to suppress changed > > information unless explicitly requested. This would also allow > > us to check the whois query logs for those requesting it ...;-). > > Does anyone know if this would break any knows scripts or uses > > of the database? > > > > Daniel > > Hiding the changed: lines definitely breaks every system that keeps > _copies_ of the entries because it is impossible to update entries > from these copies without trashing the existing entries. I guess the most of these uneducated users use the www interface of the RIPE-DB and not a client program. So in the first step it should be filtered out "changed" fields on the web. This probably doesn't effect the system you wrote about. Then the whole db software could be modified in such a way that it reponses just a fake line (changed: you-are(a)not.interested.in-it 990101) unless the query contains a "-C almost_secret_password_here" option. The so called "password" might be retrieved by e-mail from the RIPE NCC. > And if you make the changed: line availables optionally then those > who want to use addresses will quickly figure out how to get them. This is true. But if someone knows that the "changed" field is missing he knows too what is it for. The newbies who write these harrasing mails know nothing about RIPE database so they won't miss this info. They will happy without it too. ;-) This is like medicines. Its are hazardous in hand of a child so we must keep the drugs locked away. However adults can open the locker in the bathroom easy if the need some pills. Regards Gabor

2 1

RE: "changed" field should be deleted
by Christian Panigl, ACOnet/UniVie 05 Jun '98

05 Jun '98

>Date: Fri, 5 Jun 1998 11:12:32 +0200 >From: kissg(a)sztaki.hu > >What is your opinion? Hi Gabor, by chance I know someone who already had similar thoughts, guess who ;-) >(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.) How about changing our mail address, let's say every two weeks ?-( I'd vote for your first suggestion: >- modified database software that hides the *ch field. *ch's could > be retrieved with some extra efforts only Probably this could/should be combined with introducing "real" changed records (added by the database software using mail-header of update). Cheers Christian --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

1 0

Beta Version of the State of the Database Reports.
by RIPE Database Administration 05 Jun '98

05 Jun '98

Dear Colleagues, At the Database Working Group session at RIPE 31 in Stockholm recently, it was announced that the beta version of the State of the Database Reports would be published. The URL is: <http://www.ripe.net/db/state/index.html> Comments and questions to <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

[funEstuff] SELF RUN BUSINESS
by success＠highpro.com 04 Jun '98

04 Jun '98

============================================= We value your Free Subscription to funEstuff! THIS MONTH'S DRAWING: FREE FAX MACHINE!! ============================================= ---- There is a merger in the works involving Polygraph Records, Warner Brothers, and Keebler. It will be called Poly-Warner-Cracker. ---- The boy's clothing shop was giving away balloons to customers. One little fellow asked if he might have two. "Sorry," the clerk said, "but we give only one balloon to a child. Do you have a brother at home ?" The youngster was always truthful, but he wanted another balloon badly. "No," he replied regretfully, "but my sister does, and I'd like one for him." ---- SELF-RUN, ON-LINE BUSINESS FREE WEBPAGE, FREE MARKETING TOOLS "HOTTEST" INTERNET BUSINESS TODAY NO SIGN-UP FEES, NO QUOTAS TO MEET CHECK MY WEBSITE AT http://members.xoom.com/mat1014/ ============================================= Your Free Subscription is always appreciated. You may cancel your membership, at any time, by sending email to: success(a)highpro.com with the word REMOVE in the subject line. If you have any questions about this list, contact us at 409/788-5867 or visit us online at: http://www.tssolutions.com/ =============================================

1 0

[funEstuff] Subscription Confirmation
by success＠highpro.com 03 Jun '98

03 Jun '98

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ We appreciate your Subscription to funEstuff! _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Your Email has been entered into our system as a subscriber to "funEstuff". This email is being sent out in an attempt to confirm your Free subscription. We do not condone or tolerate "spam" in any shape or form. If your email has been entered in by someone other than yourself, or you wish to discontinue your subscription, REPLY to this email with the word REMOVE in the subject line. We will make sure that you do not begin receiving the regular funEstuff updates, announcements, and surveys. To remain subscribed to this Free list, simply ignore this email. Your subscription will begin within a few days. You may modify your marketing and information preferences at any time, by visiting our online registration form: http://www.tssolutions.com/funestuf.htm _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Total Success Solutions, Inc believes in and supports the responsible use of bulk email advertising to targeted and subscribed audiences, only. For more information, call us at 409/788-5867, or visit us at http://www.tssolutions.com/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0