November 1993 - db-wg - mailman.ripe.net

NIC Handles
by Daniel Karrenberg 02 Dec '93

02 Dec '93

This is the NCC's current thinking aout NIC handles. This is a quick dump, so If you have questions, please ask. Please comment! Daniel As decided at the last meeting we need to introduce unique handles in order to deal with ambiguities in the RIPE database. Especially accidental overwriting of persons will be a problem in the future with more than 10000 persons in the database now. After some discussion with the InterNIC we have concluded that a worldwide handle space is not realistic. In fact Australia has already started with their own space. Therefore we propose to start issuing RIPE handles as soon as technically feasible. Person handles will then be of the form XYZ123-INIC ABC457-RIPE .... Each physical person will eventually have one such handle only in order to facilitate database exchanges between NICs and database maintenance. RIPE handles will be assigned by sending in a person entry to auto-dbm with somethin like nic-hdl: assign which will cause the entry to be added with a new unique handle assigned. If there are other persons with the same name their entries will be returned as a check against multiple registrations. The NCC will *not* automatically assign handles to persons without handles on a "flag day". Local registries or the persons themselvews will have to do that. The reason for that is that all conflicts would need to be resolved beforehand and all persons notified of the change. This is too cumbersone, if not impossible. The NCC will flag possible conflicts present in the database today and help resolve them by notifying everyone involved and by assigning handles to all persons involved if necessary. In the future, handles will have to be used in the contact attributes (tech-c, admin-c, zone-c) in order to maintain unambiguous references. The recommended value for the contact attributes will be to list *both* name and handle in order to guard against typos in handles. Name only and handle only will also still be allowed. It might be necessary to disallow name only at some point when the majority of persons have a handle. Daniel

2 3

Re: NIC Handles
by Bjorn Eriksen 30 Nov '93

30 Nov '93

>After some more discussion with the InterNIC it looks like we cannot >avoid giving *everyone* in the RIPE database a handle soon. Otherwise >the database exchange with the InterNIC would be too difficult. Just wondered how long it would take until something like a handle had to be introduced. --Bjorn

1 0

Re: NIC Handles
by Daniel Karrenberg 30 Nov '93

30 Nov '93

After some more discussion with the InterNIC it looks like we cannot avoid giving *everyone* in the RIPE database a handle soon. Otherwise the database exchange with the InterNIC would be too difficult. So contrary to what I said last week we will need to do that soon. I will send out a draft RIPE document later today. Please comment a.s.a.p. so that we can act quickly. Daniel

1 0

Re: NIC Handles
by Erik-Jan.Bos＠SURFnet.nl 30 Nov '93

30 Nov '93

Daniel, > This is the NCC's current thinking aout NIC handles. > This is a quick dump, so If you have questions, please ask. > Please comment! My 2 cents... > As decided at the last meeting we need to introduce unique handles in > order to deal with ambiguities in the RIPE database. Especially > accidental overwriting of persons will be a problem in the future with > more than 10000 persons in the database now. > > After some discussion with the InterNIC we have concluded that a > worldwide handle space is not realistic. In fact Australia has already > started with their own space. > > Therefore we propose to start issuing RIPE handles as soon as > technically feasible. Person handles will then be of the form > > XYZ123-INIC > ABC457-RIPE > .... > > Each physical person will eventually have one such handle only in order > to facilitate database exchanges between NICs and database maintenance. > > RIPE handles will be assigned by sending in a person entry to auto-dbm > with somethin like > > nic-hdl: assign > > which will cause the entry to be added with a new unique handle > assigned. If there are other persons with the same name their entries > will be returned as a check against multiple registrations. > > The NCC will *not* automatically assign handles to persons without > handles on a "flag day". Local registries or the persons themselvews > will have to do that. The reason for that is that all conflicts would > need to be resolved beforehand and all persons notified of the change. > This is too cumbersone, if not impossible. > > The NCC will flag possible conflicts present in the database today and > help resolve them by notifying everyone involved and by assigning > handles to all persons involved if necessary. > > In the future, handles will have to be used in the contact attributes > (tech-c, admin-c, zone-c) in order to maintain unambiguous references. > The recommended value for the contact attributes will be to list *both* > name and handle in order to guard against typos in handles. Name only > and handle only will also still be allowed. It might be necessary to > disallow name only at some point when the majority of persons have a > handle. A still open question is what to do with people residing in Europe having a InterNIC handle already. You surely want these people to have a RIPE handle as well, I presume. This, however, would mean that such a person has two handles, which is confusing. Possible solutions?: - flag these people and assign them a RIPE handle and reject the INIC handle. - leave the INIC handle as is, and use this inside the RIPE Data Base. - Live with the confusion of more than one handle per person. A totally different thing is that there are people in the data base more than once. I guess this is really hard to flag automatically, but this needs to be sorted out as well. __ Erik-Jan.

6 5

Re: dom-net tag under domain
by Tony Bates 30 Nov '93

30 Nov '93

Actually, you need a little more so you only get one occurence of a net per object. This should take care of that. while (<>) { chop; if(/^\s*$/) { %done = (); } if(/^di:/ || /^dom-net:/) { ($tmp,$value) = split (/\s+/, $_, 2); printf "%-10s", $tmp; @list = split(/\s+/,$value); foreach $j (0..$#list) { $net = &munge($list[$j]); if(!$done{$net}) { printf " %s", $net; } $done{$net} = 1; } print "\n"; next; } else { printf "%s\n", $_; } } sub munge { local($str) = @_; local($ind) = 0; local($val) = ""; local(@add) = split(/\./, $str); foreach $ind (0..$#add) { if ($add[0] < 128) { $val = "$add[0]".".0.0.0"; return $val; } if ($add[0] < 192) { $val = "$add[0]"."."."$add[1]".".0.0"; return $val; } if ($add[0] < 224) { $val = "$add[0]"."."."$add[1]"."."."$add[2]".".0"; return $val; } } } Hope this was of some help, --Tony.

1 0

dom-net tag under domain
by bonito＠nis.garr.it 30 Nov '93

30 Nov '93

Dear NCC people, I think that too strict sintax checking is applied in the case of the dom-net database field. An example follows. We are deploying technology to obsolete networks classes (A,B,C,...) and at the same time the RIPE database checking rules do not take into account the actual usage of dear old subnetworks? In practice very often a number of subnetworks of a class B network are used to host machines in a domain while other subnetworks are used to host machines of a different domain. This is common for large networks in a city. We would like the checking rules to be relaxed in this case. Could you please do that? ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- Forwarded message: > From giuliana Mon Nov 29 14:47:06 1993 > From: giuliana (Giuliana Tamorri) > Message-Id: <9311291347.AA07375(a)jolly.nis.garr.it> > Subject: > To: bonito (Antonio_Blasco Bonito) > Date: Mon, 29 Nov 93 14:47:04 MET > X-Mailer: ELM [version 2.3 PL11] > > domain: astro.it > x400-domain: c=it; admd=garr; prmd=astro; > org: astronet > admin-c: Leopoldo Benacchio > tech-c: Roberto Di Luca > postmaster: Roberto Di Luca > zone-c: Roberto Di Luca > nserver: 137.204.64.15 boas3.bo.astro.it > nserver: 192.12.192.5 dns.nis.garr.it > dom-net: 137.204.64.0 137.204.51.0 192.94.71.0 150.217.20.0 > dom-net: 143.167.30.0 147.162.26.0 130.192.100.0 140.105.72.0 > dom-net: 192.84.153.0 192.9.200.0 > remarks: national astronomical observatory network > changed: <DILUCA(a)ALMA02.CINECA.IT> 930602 > source: TEST > *ERROR*: syntax error in "dom-net" - illegal IP network number 137.204.64.0 > *ERROR*: syntax error in "dom-net" - illegal IP network number 143.167.30.0 >

3 6

Fundamental problem with mandatory field zone-c
by Andreas Schachtner 27 Nov '93

27 Nov '93

domain: AIC.DE descr: AIC Software GmbH descr: Muenchen admin-c: Gottfried Bartmuss tech-c: Gottfried Bartmuss source: RIPE *ERROR*: mandatory field "zone-c" missing *ERROR*: mandatory field "changed" missing ; <<>> DiG 2.0 <<>> @deins.informatik.uni-dortmund.de aic.de. any ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 1 ;; QUESTIONS: ;; aic.de, type = ANY, class = IN ;; ANSWERS: aic.de. 86400 MX 190 mail.Germany.EU.net. ;; ADDITIONAL RECORDS: mail.Germany.EU.net. 86400 A 192.76.144.65 ;; Sent 1 pkts, answer found in time: 18 msec ;; FROM: foobar to SERVER: deins.informatik.uni-dortmund.de 192.35.64.34 ;; WHEN: Fri Nov 26 11:42:36 1993 ;; MSG SIZE sent: 24 rcvd: 75 There is no zone for aic.de, thus there is no zone contact. Opinions ? Andreas Schachtner afs(a)Germany.EU.net === ____ === EUnet Deutschland GmbH === / / / ___ ___ _/_ === Emil-Figge-Str. 80 === /---- / / / / /___/ / === D-44227 Dortmund === /____ /___/ / / /___ / === ===== ===== Tel. +49 231 972 00 ===== Connecting Europe since 1982 ===== Fax +49 231 972 1111

6 6

Re: NIC Handles
by Erik-Jan.Bos＠SURFnet.nl 25 Nov '93

25 Nov '93

Andrew, > > A still open question is what to do with people residing in Europe having > > a InterNIC handle already. You surely want these people to have a RIPE > > handle as well, I presume. This, however, would mean that such a person > > has two handles, which is confusing. > > People should have just one handle; not two. Agreed. One person, one SSN. :-). > I think that the question that we are trying to solve is: > If someone does not have a handle of any sort and we (some > registry - like RIPE or the NIC) want to assign him one, how do > we assign him one such that the handle is unique? Sure. This is raised in the document Daniel submitted. I just raised two additional things: - people already having a INIC-handle - some people occur in the RIPE Data Base more than once If we feel this is outside the scope of the proposal, let's quit the issue. My personal opinion is that we need to address this as well. __ Erik-Jan. NIC-handle: EJB (or should it be EJB-RIPE).

1 0

Syntax errors in database
by Marten Terpstra 23 Nov '93

23 Nov '93

Folks, As promised at the last RIPE meeting, we have run a full syntax check on the complete database, and the results of that check are available for anonymous ftp. The files are split by object type, and contain only objects that generated a warning or error. If you have some time to maybe look at some of your info, please look in: ftp.ripe.net:ripe/dbase/errors/ If you have questions about errors/warnings found, please let us know. -Marten

1 0

Discrepancies between Merit and RIPE DB
by Laurent Joncheray 11 Nov '93

11 Nov '93

Here are the differences between the Merit and the RIPE databases: Number of entries: 3791 No difference: 608 (16%) Small diferences: 1354 (35%) Substrings: 968 (25%) Typos: 481 (12) Order: 78 (2%) Punctuation: 51 (1%) Abbreviations: 244 (6%) One Word only: 75 (1%) Differences: 1829 (48%) 100%: 277 (7%) 80%: 303 (7%) 60%: 335 (8%) 40%: 463 (12%) 20%: 451 (11%) A file with the list of addresses and differences is available on request. -- Laurent Joncheray, Merit Network Inc, 1071 Beal Avenue, E-Mail: lpj(a)merit.edu Ann Arbor, MI 48109, USA Phone: (313) 936 2065 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

1 0