- db-wg - mailman.ripe.net

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