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 26 Nov '93

26 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

discrepancies RIPE - InterNIC
by Laurent Joncheray 11 Nov '93

11 Nov '93

Thanks to the InterNIC folks, the InterNIC data relative to the Network numbers is available on a flat file on merit.edu. We ran a comparison between the InterNIC and the Merit data, and between the RIPE data and the InterNIC data. since RIPE is authoritative for the European information and the InterNIC is authoritative for everything else, it seems most important to address those discrepancies (RIPE/InterNIC). Here is the result of the first comparison between RIPE and InterNIC: (The data may be old for some networks, and our program may have some bugs... The result for the Merit/InterNIC data are not provided) Number of entries: 10423 Unregistered in NIC DB: 5298 (50%) No difference: 108 (1%) Small differences: 2047 (19%) Substrings: 1604 (15%) Typos: 510 (4%) Order: 356 (3%) Punctuation: 21 (0%) Abbreviations: 186 (1%) One Word only: 5 (0%) Differences: 2970 (28%) 100%: 758 (7%) 80%: 498 (4%) 60%: 494 (4%) 40%: 723 (6%) 20%: 497 (4%) Remarks: - 10423 represents the number of networks and blocks in the RIPE DB; each block is counted as 1 network. - The addresses for the RIPE networks are got from the 'Administrative Contact' entries. For 10423 networks, 224 do not have a administrative contact entry in the persons databases. In such a case we use the 'description' attribute to get the address. Some entries are duplicated in the person DB, which creates some strange addresses (e.g. 193.84.64.0 -> Alexandr Modry) - 'Unregistered in NIC DB' means the network is part of the RIPE block in the NIC BD, but does not have its own entry. - 'Substrings' means all the words of one address are on the second address (e.g. "Celisoft Data AB, Box 718, S-941 28 Piteaa, Sweden" and "Celisoft Data AB, Celisoft Data AB, BOX 718, S-941 28 PITEAA, SWEDEN") - The differences are given in percentage of number of different words. 100% means 80% to 100% of the word are differents. We also take into account the typos, abbreviations, punctuation, etc... which are not a 'difference' per se. - The program which compares the addresses takes about 20s for 10000 entries. The program which reads the InterNIC data and formats them for comparison takes about 20 minutes. We'd like to set up a plan with RIPE and the InterNIC to eliminate the discrepancies. Merit has a list of the 5298 networks without entry in the NIC DB and can provide a detailed list of the address differences for the other inconsistences. Do you all have any suggestions as to how we can proceed to resolve this problem? Laurent & Enke. PS: Could InterNIC provide your flat file periodicly? (once a week?) PS: Any comments are wellcome.

3 2

Re: A Question
by Daniel Karrenberg 03 Nov '93

03 Nov '93

Jack, sorry about that late reply. First I have been away and then swamped. The answer has been a little longer than expected. Thus I CC it to the relevant RIPE working groups too fort their information. Daniel > Haven't mailed for awhile. I hope everything is going well over the > pond. I was wondering if you could fill me in on a little RIPE > philosophy. Tall order. :-) If we keep it down to specifics ... > Right now, its my understanding that authorized users can > automatically update the ripe database. If that is correct, how do you > make sure that what the authorized user is telling you is the correct > information. The original RIPE DB authorisation scheme: "No authorisation but *very* good audit trails." Anyone can change anything in the database but it will be logged. True, if you are mailicious and really determined you can do things and we will not be able to trace you far. But we will know what was done when and from where and we will be able to take appropriate action. We have decided to cross that particular bridge when we get to it. Together with a very quick response to queries about update problems this has worked rather well. After three years of experience with now 38,000 objects in the database and just under 1000 updates on an average working day I can not recall more than about a dozen incidents of unintentional changes being made by third parties. All of those have been resolved rather quickly and none has been intentional or malicious. Since we are now starting to do routing registry functions which are critical to operations we are starting to introduce some authorisation for the routing policy elements in the database. Some objects will not be changeable at all but by an authorised guardian. Currently these are some deprecated objects nad the autonomous system and community objects. Additionally some attributes will be guarded. The most important is the "aut-sys" attribute of the network object which defines membership of a network in an AS. These attribute will not be updated or updatable via the normal method but via a totally separate authorised method by the guardians of the respective autonomous system. The authorisation method for this will be Unix login security in most cases. You can read more about all this in ripe-81 ripe-96 ripe-89 ripe-72 and others. > An example: > > Say I'm a mean guy and I want to register a net that I do not own, and > is currently not in the RIPE database, to myself before my competitor > has registered it. How do you make sure that I'm allowed to register > this new net in the database? We do not. But we keep track of registry assignments separately from the database. If someone claims a network and has no assignment from the appropriate registry (either the NCC or a local registry) then he looses. > The only way I can check this today is > to see if the internic has given the net out and if it is registered > to the apporpriate person sending in the database addition. Same thing here. > Now if I'm > a provider, I do not "own" this address so things get a little > confusing. Not at all. The registry has the obligation to keep a record of what they assigned separately from the database and to register networks in the RIPE database no less than 24h after assignment. So there will be a trace. Also a flag will be raised if such an assignment is made for a net already in the database. At the NCC we keep simple SCCS files (yes I am *that* old) for the register. Together with the database audit trail this is more than adequate to document who did what when. We also keep an archive of all registry mail messages and faxes (full-text indexed with WAIS). We also have a filing cabinet used for those old fashioned hardcopy requests. It is not too full yet so we can keep office supplies and other stuff in it as well. :-) If there is a conflict both the datbase audit trails and the register of the registry concerned will be examined. If there are conflicts the latter is most likely to be ruled authoritative. To date such a case still has to happen - apart from administrative snafus which *do* happen once in a while. Daniel

1 0