- db-wg - mailman.ripe.net

Top 100 Maintainers List
by RIPE Database Manager 04 Aug '99

04 Aug '99

2 1

Re: Interesting object in the RIPE database
by Steven Bakker 11 Jul '99

11 Jul '99

>>>>> On Wed, 7 Jul 1999, "RLE" == Robert_Martin-Leg=E8ne wrote: RLE> Doesn't mean that it makes sense in the IP Registry world. Let's be RLE> practical. And besides, classful addressing is a Thing of the Past (ahem). The BSD way of doing it is clever, but complicated and it has no place in the DB, IMO. I always understood that the DB software would pad missing octets at the end of an IP address, no ambiguity there. What I'm surprised about is that the DB apparently allows someone to register address space that's most likely not even theirs... Of course, once it gets allocated and entered into the DB, a conflict will be detected and flagged (right!?), but until then, the error will go undetected. Is this a feature? Cheers, Steven

4 3

Interesting object in the RIPE database
by Niels Bakker 07 Jul '99

07 Jul '99

Hi, I noticed the following object in the RIPE database this afternoon: inetnum: 195.59.213.0 - 213.127.0.255 netname: WILLIAMBROOKES-TF13-GW descr: William Brookes School country: GB admin-c: PC2598-RIPE tech-c: IH22-ORG rev-srv: ns0.insnet.net rev-srv: ns1.insnet.net status: ASSIGNED PA mnt-by: AS5378-MNT changed: cliveg(a)insnet.net 19990706 source: RIPE (I stumbled over it while querying the RIPE database for an object within the APNIC database while accidentally omitting the -a option.) Clive Galway (the creator of this object) told me after I contacted him that he had entered the following information into the template: 195.59.213.0 - 213.127 instead of 195.59.213.0 - 195.59.213.127 He added, "funny that it dont complain though" - I agree wholeheartedly with him here. :) A check for the number of dots in the inetnum: line should be quite easy, and similar to this: # fix for people who don't include the first two or three octets s/^(\d+\.\d+)\.(\d+\.\d+) - (\d+\.\d+)$/$1.$2 - $1.$3/ s/^(\d+\.\d+\.\d+\).(\d+) - (\d+)$/$1.$2 - $1.$3/ if ($_ =~ /^\d+\.\d+\.\d+\.\d+ - \d+\.\d+\.\d+\.\d+$/) { &complain; } I believe there is a sub to check whether something is a valid IP address but can't find it offhand in my (by now pretty dated) copy of the RIPE database software... With regards, -- Niels Bakker, * * EuroNet Internet BV Network Operations * * Herengracht 208-214 * 1016 BS Amsterdam NJB9 * +31 (0)20 535 5555

3 2

Converting named references to NIC handle references
by Engin Gunduz 29 Jun '99

29 Jun '99

Dear collegues, As discussed and agreed to in the mailing lists, we will be converting unambiguous named references in the admin-c and tech-c fields of as-macro, autnum, community, dom-prefix, inet-rtr, mntner and role objects to NIC handle references, on 1 July, 1999, at 17:00, GMT. The process will take around half an hour, and during the process the updates will be queued. Whois queries will not be affected. The maintainers of the affected objects will get notifications about the changes. The conversion on domain and inetnum objects will be done at a later date, due to substantial time they require for this process. If you have any questions, please do not hesitate to contact us. Regards, Engin Gunduz RIPE NCC DB Group

1 0

T1
by OrderOffice - ICP Lueck und Lanzrath GbR 25 Jun '99

25 Jun '99

T1

1 0

address field limitation???
by Pedro Goncalves 25 Jun '99

25 Jun '99

Hi I would like to know what is the char limit (if any) for the address field. Some of my submitions apparently where returned because of the usage of more than 64 chars. Best regards Com os melhores cumprimentos. Pedro Gonçalves Telepac, SA Tel: 351-1-7907354 Fax: 351-1-7907001

2 1

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) 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 --------------------------------------------------------------------------

3 2

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

>I explicitly excluded those objects from this run. Great. >I knew this thing was going to be a bit polemic so I am trying to split into >smaller problems and stages that we can all agree to. Well, complex, at least. I fully support your approach! >Hopefully every step will reduce the number of objects that need repairs. And >believe me, it's not the same to have to fix 250000 objects than to fix 25000. >Somehow the latter seems a bit more feasible (from a "let's deal with this" >attitude). Certainly. >So, can we agree to proceed with our suggestion as stated below? >** >Change references by names to references by nic handle where these are unique >(there are not already more than two persons with the same referenced name). >** I agree. >For the cases where the ambiguity is already there: we'll look at them, try to >categorize them Sounds interesting. I really like the approach taken by Poul-Henning with his IP address page. Maybe we can come up with a similar list, e.g. categorized by object type, and within the object type by LIR, TLD, AS-#, Maintainer... >and maybe identify another subset which can be handled by >drawing information from some other source. >We'll get back to you with our suggestion (and we take the two you mention as >input). Any input is most welcome. Wilfried.

1 0

Re: Modifying references to contact info in the RIPE DB
by Janos Zsako 24 Jun '99

24 Jun '99

> From owner-db-wg(a)ripe.net Thu Jun 24 15:23:02 1999 > From: Joao Luis Silva Damas <joao(a)ripe.net> > ALMOST NONE except that: > from that point on if someone else with a name equal to one already in the > database is entered into the database the reference will not be made ambiguous > while if we leave it as a reference by name it sure becomes ambiguous. I agree with Joao that there is virtually nothing to lose. I don't think it is better to have a reference by name with a single incorrect instance of a person object with that name, rather than a NIC-handle reference to the same incorrect instance... (By incorrect instance I mean a person object with the same name, but who has nothing to do with the referring object). At the same time the benefit is obvious (see above). Also, the longer one delays this process, the better the chances to have several instances to be handled manually (i.e. to try to identify the correct person object from several ones with the same name). Just my 2 filler (.01 HUF). :)) Janos

1 0

Re: Modifying references to contact info in the RIPE DB
by Janos Zsako 24 Jun '99

24 Jun '99

> From owner-db-wg(a)ripe.net Thu Jun 24 14:35:25 1999 > From: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> > One of the key things might be to make sure that we (you :-) can perform > a roll-back, if it turns out that we've messed up things badly... My feeling is that if one replaces the name reference with the NIC-handle, at least as long as the referenced person object is not deleted (which I suppose cannot be deleted once it has an other object referencing it), the roll-back is always possible (i.e. one could re-substitute the NIC-handle with the name). Although, I feel this would be in the best case useless, since either there is no other person object with the same name, or the other object(s) was(were) added later. Janos

1 0

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

Hi Joao! >So, in spite of the concerns raised (valid as they are) I would still >vote to go ahead on this one as proposed. > >What do people think? Well, some as yet unstructured rants, off the top of my head... I'd love to see some sort of test-run being performed, e.g. going ahead and putting the result up as the (or an additional) test db? One of the key things might be to make sure that we (you :-) can perform a roll-back, if it turns out that we've messed up things badly... Is there any chance to do some sort of dry-run, and put up some sort of list of cases deserving investigation? Poul's page is a very good thing, indeed, although tackling a different aspect. My reasoning is that whatever can be fixed by humans, in a distributed project, before the brute-force attack would make life easier. Most probably basic rule #1 applies to my comments: use the brain before using the keyboard :-) 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 --------------------------------------------------------------------------

2 1

Modifying references to contact info in the RIPE DB
by Joao Luis Silva Damas 24 Jun '99

24 Jun '99

Dear all, the Database consistency project has been going forward in its goals since RIPE 33 (eg. addition of nic handles to all objects without one.) Statistics and reports about the "status" of the database can be seen at http://www.ripe.net/db/state/. We will keep adding information to these pages as the project progresses. We are now at the point where we would like to tackle the issue of references by name in the admin-c, tech-c and zone-c. As a next step, we would like to have references by nic handles (which are unique) instead of references by name (which can be non -unique). At this point, we would like to automatically go through all the references by name which can uniquely be assigned to a person or role object and substitute them by references to their nic handles. This will prevent these references from becoming non-unqiue in the future. Later we will go through the process of fixing the non-unique references left in the database. This process requires user intervention since we can't decide who "owns" a particular set of resources. For this later stage, we will be preparing reports that we will send to all maintainers for whom we detect objects with inconsistencies and try to get them fixed. Information about this part will be sent to the lists in a few weeks. We would like to do this after as much as possible has been done by automatic means to correct inconsistencies so that human effort is reduced to a minimum. If there are any concerns regarding this move, please make them known before next Friday (June 25th). Looking forward to your comments, Joao Damas Database Group RIPE NCC

4 6

Changing old format dates in the RIPE DB
by Joao Luis Silva Damas 24 Jun '99

24 Jun '99

Dear all, we are going to start with the procedure to modify all the dates in the changed fields of database objects that were using only two figures for the year. After the modifications, the year part of the date will contain 4 digits. Changed fields which currently do not have a date will not be changed (*) This is taking place according to the action points agreed on the Vienna RIPE meeting. The process will be carried over the next few days due to the time it takes to re-index some of the bigger files. Regards, Joao Damas DB Group RIPE NCC (*) These objects will not be updatable by the user unless a date is included at update time or the only changed field without a date is the last one, in which case the database automatically fills in the date at which the update takes place.

1 0

Update processing delayed
by RIPE Database Administration 22 Jun '99

22 Jun '99

Dear Colleagues, the database is very loaded now, due to some huge updates sent tonight. The queue of waiting updates is very long and you should be prepered for waiting times of several hours before your update gets processed. Please do not resend your updates. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Roman Karpiuk ____________________________ The RIPE NCC Database Group.

1 0

Adding nic handles to objects without one
by Joao Luis Silva Damas 16 Jun '99

16 Jun '99

Dear all, as discussed and agreed to during discussions in the mailing lists and at the RIPE Meeting in Vienna, the RIPE NCC will be adding newly generated NIC handles to person objects that do not currently have one. Over the last days we have been testing the procedures to do this in a non-disruptive way. Unfortunately, due to the nature of the current database, the process needs about 5 hours to run. Due to this and to avoid interactions with nightly jobs that create several copies of the files, including the ftp site and the full text search indexes, we will stop updates tomorrow Tuesday at 19:00 (Amsterdam time). This will cause all updates to the DB sent after 19:00 to be queued for later processing that night. There is no need to send updates more than once. Queries will not be affected. That is, the whois server will keep answering queries normally. During the process, objects without nic handles will get unique new ones and also a "changed" attribute will be added with tomorrow's data and ripe-dbm(a)ripe.net as the author of the change. This is for future reference. If you have any questions, please do not hesitate to contact us. Best regards, Joao Damas DB Group RIPE NCC

2 1

RE: status on RIPE-DB rewrite
by Wilfried Woeber, UniVie/ACOnet 07 Jun '99

07 Jun '99

Rick, >can anyone give a status on the ripe-db rewrite in 'C' http://www.ripe.net/meetings/ripe/ripe-33/pres/db-reimpl/index.html might provide you with some answers. I'm sure RIPE NCC staff can give more details, if required. 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 --------------------------------------------------------------------------

2 1

Tagging of IP adresses / Application-Database
by Nacamar AS Guardian 07 Jun '99

07 Jun '99

Hi, at RIPE-Meeting 33, the issue on the agenda of the lir-wg of "Tagging of IP adresses and ANTI SPAM" was rejected. Partly, because this has been implemented by Paul Vixi, http://maps.vix.com/dul Further, it was felt that these tags should not be an addition to the IP-Objects, because it has a much broader range of possible applications. So, the issue was handed over to the db-wg to think about a new application-registry. Such an application-object could look like: >>> location: [mandatory] [single] [primary/look-up key] app-type: [mandatory] [single] [primary key] app-subtype: [mandatory] [single] [primary key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] <<< Location would be a range of IP-Addresses or maybe a hostname, app-type a value/keyword like "nameserver", "dialin", "mail" etc., app-subtype a more detailed code for the application, like root-nameserver, tld-nameserver, cc-nameserver, etc. Details to be discussed... Then descr, contacts etc, just the usual stuff. Technically, this shouldn't be too hard, but the main questions remain on the administrative side: - who would use this database, and for what purpose (Anti-SPAM, better route-flap-dampening ...) - who should insert/maintain the contents - how to determine if the contents are 'legal', e.g. come from the 'owner' of the mentioned ip-ranges/hosts - what to do if someone protests against some contents, or claims damages because of some contents Just to spark a bit of discussion... Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Robert-Bosch-Str. 32 D-63303 Dreieich +49 6103 993 0 Voice Germany +49 6103 993 222 FAX gurt(a)nacamar.de ------------------------------------------------------------------- Titanic 12 - Hiroshima 45 - Tschernobyl 86 - Windows 95 - Silvester 99

3 4

Re: Tagging of IP adresses / Application-Database
by Wilfried Woeber, UniVie/ACOnet 04 Jun '99

04 Jun '99

=> >> back to basics: The only thing I wanted was an attribute => >> which said "SMTP connections from these IP numbers shouldn't happen" Yup, that was where it came from :-) And we are grateful to you for seeing this "spark" to get the whole discussion going! => > => >'overloading' of the current IP-Database with additional, => >basically unrelated informations was not wanted. => => Rather than bloat the idea to that size, I thing I'd rather drop => the proposal then. = =Ok, that would be the easiest way to get this issue done, sort of... Well, from the "users'" point of view, the innards of the implementation shouldn't be that important ?? >On the other hand, the administrative overhead >for the IP-Database with tags as extensions >is likely to be at least the same >as for a new, separate database. During the various discussions we hit a few interesting aspects (non-exhaustive list): - people do have a broad set of ideas what they woukd like to see documented. From dial-up use of IP addresses to "golden" networks for registry servers or root NS, to web-cache sites/peerings, to IPv6 tunnels... - the problem of over-loading existing objects, both schema-wise as well as maintainance-wise. E.g., for a larger ISP there's a good chance that the LIR staff wouldn't want to/be able to maintain application level entries... - the problem of authority for the data. We do have "over-loading" already, within the RIPE-DB. . I.e. the DB is (formally) authoritative for IP numbers, . it's a "reasonable" place to offer a routing registry service, but with much less (formal) authority attached by the NCC . it's offered/used as a repository for DNS data, discussion has started if "authority" for that subset should be moved to CENTR . an application type registry probably needs some sort of environment. Learning from DNS, I suppose the NCC is very reluctant to spend implementation effort unless we can come up with a model for use, authority and - eventually - funding. But, this list is emphasising the potential stumbling blocks... I'd be much more interested in proposals on the use and setup, how to maintain the data, how to derive and attach credibility, and the like. The floor is your's! Input, please! 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 --------------------------------------------------------------------------

1 0

status on RIPE-DB rewrite
by Rick H. Wesson 04 Jun '99

04 Jun '99

can anyone give a status on the ripe-db rewrite in 'C' thanks, -Rick

1 0

New RIPE DB sw version
by Joao Luis Silva Damas 04 Jun '99

04 Jun '99

Dear all, the RIPE NCC is happy to announce version 2.3 of the RIPE Database software. This new version introduces complete support for the IPv6 address objects. Only the RIPE NCC can introduce objects with value ALLOCATED in the status field of IPv4 address objects. This reflects the current registration policy. Some other minor features and a number of bug fixes have been introduced. For more details, please see the release notes included below and on the software package. This new version is available immediately from ftp.ripe.net and will be used on whois.ripe.net starting next Monday (7th June). Regards, Joao Damas DB Group RIPE NCC

1 0

Proposal to change default source search behavior in the whois server
by Jake Khuon 27 May '99

27 May '99

Currently, the RIPE whois server returns a result from a single-source (RIPE) search by default. One needs to pass a -a flag in order to obtain multiple-source returns. Because of this behaviour in conjunction with the necessity to allow a "defaulted" query to return inetnums, the architecture of the database is limited to a single source. For those organisations who may wish to run their own registry and participate in mirroring, this poses a considerable issue. I propose that the behaviour be modified so that the default would be to return a single-match first-hit from multiple-source search. That is, a query will return only one result but it will search through the source search order and return the first match it finds rather than simply stopping at the RIPEdb. -- /*====================[ Jake Khuon <khuon(a)GCtr.Net> ]======================+ | Network Statistics Engineer, NSM/Net-Eng /~ |2 () |\| ~|~ | @ |2 | | VOX: +1(408)328-4828 Fax: +1(408)328-4806 _/~ G L & B A L C E N T E R | +============[ 1154 East Arques Avenue, Sunnyvale, CA 94086 ]============*/

1 0

2. Draft, proposed agenda DB-WG meeting RIPE-33, Thu.,May 6
by Wilfried Woeber, UniVie/ACOnet 05 May '99

05 May '99

Dear WG participants, dear WG-Chairs, here's the final draft agenda for the DB-WG meeting. 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-33, May 1999, Vienna, AT 2. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing - review of action items B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - current status of PGP deployment C. DB SW Re-implementation (RIPE NCC) - progress, milestones/roadmap, deployment, documentation - operational aspects, mirrors, clients - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . others? D. I-D draft-ietf-rps-auth-??, -rps-dist-?? (??) - RIPE region requirements/comments - any progress E. DB Consistency Project (RIPE NCC) - status update F. IPv6 issues - what are the loose ends? . Routing registry (RPSLng ?) . Objects . IP-registry X. IETF report(s) if any :-) Y. Input from other TFs/WGs - LIR-WG: application specific registries? DUL, Root-NS, TLD-NS,.... - DBsec TF mission accomplished? mandate for continuation? next activities, if any at all? Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 5-MAY-1999 13:46:59

1 0

1. Draft, proposed agenda DB-WG meeting RIPE-33 @ Vienna
by Wilfried Woeber, UniVie/ACOnet 23 Apr '99

23 Apr '99

Dear WG participants, dear WG-Chairs, attached please find a very preliminary agenda draft for the DB-WG meeting in Vienna in May. Any comments and proposals for modification are very much appreciated. Looking forward to see you in Vienna, 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-33, May 1999, Vienna, AT 1. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing - review of action items B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - current status of PGP deployment D. DB SW Re-implementation (RIPE NCC) - progress, milestones/roadmap, deployment, documentation - operational aspects, mirrors, clients - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . others? E. I-D draft-ietf-rps-auth-??, -rps-dist-?? (??) - RIPE region requirements/comments - any progress X. IETF report(s) Y. Input from other WGs - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 23-APR-1999 15:03:27

1 0

Adding nic handles to contact objects without one (72 chars/line)
by Joao Luis Silva Damas 20 Apr '99

20 Apr '99

Thou shall not send vi docs directly on a mail! At people's request here goes the mail again with sorter lines. Regards, Joao ------- Include message ------ Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think this summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC

3 2

Re: Objects to deprecate (OSI dom-prefix)
by Wilfried Woeber, UniVie/ACOnet 16 Apr '99

16 Apr '99

Wearing my plain DB user hat, >the RIPE NCC hereby requests from the RIPE community to consider NOT >to support the Domain-prefix object in the new RIPE DB code currently >under development. >This would mean not writing the code to support the object and dump the data >in the transition to the new code (still a few months away). I fully support this proposal. 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 --------------------------------------------------------------------------

1 0