- db-wg - mailman.ripe.net

RE: fancy route objects
by Paul Dyke 04 Nov '97

04 Nov '97

The entry by myself was generated by RIPE as an error to an email. I did try to delete it but have had no success. Can you help. Regards Paul Dyke -----Original Message----- From: Gabor Kiss (Bitman) [SMTP:kissg@sztaki.hu] Sent: 03 November 1997 12:20 To: ripe-dbm(a)ripe.net Cc: db-wg(a)ripe.net; Paul.Dyke(a)bt.net; bridge(a)unisource.ch; gaga(a)elte.hu Subject: fancy route objects Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

1 0

IMPORTANT; Aut-num objects.
by RIPE Database Administration 03 Nov '97

03 Nov '97

Dear Colleagues, The data file and index file of the aut-num objects were corrupted this morning. This caused the aut-num objects not to be available. We regenerated the indexes. However, we discovered that some aut-num objects were missing. Thus, we rebuilt the data file using a back-up copy and generated new indexes. The aut-num objects file was reliable until 00:00 hours UTC on Monday, 3 November. The whois service was reliable again at 17:00 hours UTC this evening and the ftp copy of the aut-num objects was valid again at 20:00 hours UTC tonight. We are aware that this may have caused you some inconvenience; we therefore fixed the problem as fast as we could. If you use the data in the aut-num objects file as a basis for build routing tables or any similar purpose, we recommend that you obtain a new copy of this data from our ftp-site. Only the aut-num objects were affected this morning. The other database objects appeared not to be affected. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

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

03 Nov '97

>There is another problem too: some objects do have a mnt-by, however the >mntner has auth: NONE! :( Can we assume that these objects are well maintained? >My answer is: no. I wouldn't follow that particular line of reasoning! The fact that you/he/she/someone does not *restrict access* to objects does not mean that the maintainer does not *maintain* the objects!? I think we're still mixing aspects of - access rights to objects (=access authorization) - access rights to "registry spaces" (=object creation) - authentication & identification (=credibility of data) and last but not least - object aging and checkpointing, dangling pointers, non-ref.s, duplicates etc. >Janos > >PS. I have seen this with both inetnum and route objects. Wilfried.

1 0

fancy route objects
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

2 1

Re: Who should do entries in RIPE database?
by zsako＠banknet.net 03 Nov '97

03 Nov '97

> From owner-db-wg(a)ripe.net Mon Nov 3 11:27:09 1997 > > What about creating two databases? (Two categories of objects.) > > One for objects sent by non-registries, > > and one for well maintained, authentic objects. > > This may be an orthogonal categorization. Sorry, but many of the duplicates > (triplicates ...) already carry the "mnt-by" attribute, sometimes > even two instances the same one. There is another problem too: some objects do have a mnt-by, however the mntner has auth: NONE! :( Can we assume that these objects are well maintained? My answer is: no. Janos PS. I have seen this with both inetnum and route objects.

1 0

Re: Who should do entries in RIPE database?
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

> - 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. I got further (not too serious) ideas: What about creating two databases? (Two categories of objects.) One for objects sent by non-registries, and one for well maintained, authentic objects. Peoples could send objects to the level1 database, and registries could move the correct ones to level2. Level1 objects older than 6 months will be automatically and silently deleted. Level2 objects should be updated at least once a year, otherwise a warning message goes to the maintainer registry. After a certain period forgotten level2 objects go back to level1. All current object is on level1. Regards Gabor

2 1

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