- db-wg - mailman.ripe.net

Re: RIPE Handle document
by bonito＠nis.garr.it 09 Dec '93

09 Dec '93

> > The problem of delay in registrations by "regional" > registries could perhaps be overcome by an automated > "handle assignment" service by RIPE, where a handle > could be obtained interactively by authorised persons. > Given the turnaround-time with the new DB-software, > I really don't see where there is potential for delay > in registering objects? > But maybe we could (on paper) relax the rules a bit to > officially allow the registration of person objects that > are not (yet) referenced by other objects. > The software never prohibited this, as much as I know. > As NL domain registrar I'm used to honouring requests > for (new) registrations as soon as possible. I don't > like a registration to become a multi-stage procedure: > - register the domain and associated person(s) in > my NL database; > - wait till the whole business has been submitted > to the RIPE database (weekly, automated); > - see what handles RIPE has assigned and add them > to the entries in my NL database; > - wait again till the stuff has been sent to RIPE. > Even if I would make the submission a daily one, it > would still take several days before the registration > in my NL database and in the RIPE database have been > finalised. If RIPE would provide an interactive way > of obtaining a handle, then there would be no delay. > > Piet Piet, you've clearly expressed the same worries I actually have: I don't like the RIPE registration process to become not as fast and easy as it is now! But I don't see why the solution of distributing Internet handles assignment (the actual way is not the point: using number ranges, appending different suffixes, ...) is not taken in serious consideration. ---------- ---------- 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 ---------- ----------

1 0

Re: RIPE Handle document
by Wilfried Woeber, UniVie/ACOnet 09 Dec '93

09 Dec '93

Piet and others, >True, but that would only make the problem worse: >then you could have e.g. 10 Person objects which >are each unique in their own [source] context but >which actually refer to one and the same person. >In such a case I'd still prefer to have a specific >tag (like a handle) assigned centrally by RIPE even >when the source of the object is not RIPE. I agree with your point of view, that we should thrive to have only _very_ few instances that assign handles! Everything else is calling for trouble. >The problem of delay in registrations by "regional" >registries could perhaps be overcome by an automated >"handle assignment" service by RIPE, where a handle >could be obtained interactively by authorised persons. Given the turnaround-time with the new DB-software, I really don't see where there is potential for delay in registering objects? But maybe we could (on paper) relax the rules a bit to officially allow the registration of person objects that are not (yet) referenced by other objects. The software never prohibited this, as much as I know. Maybe this is the time to think about combining the idea of an interactive handle generator and an interactive (eg. prompt-mode) (person-)object registration script, offered on a special telnet port at the NCC? Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 4065822 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 4065822 170 NIC: WW144 -------------------------------------------------------------------------------

3 2

RE: RIPE Handle document
by Wilfried Woeber, UniVie/ACOnet 07 Dec '93

07 Dec '93

>RIPE Handle > >Internet handles issued by the RIPE NCC are called RIPE handles. >The purpose of a RIPE handle is to uniquely identify a person in the >RIPE network management database and other related databases that >choose to use it. so we manufacture Internet Handles! >... >All persons in the RIPE database must have an Internet handle. > agreed. >Every person in any of the databases keeping contact information >should only use Internet handle. sure enough, probably this isn't telling me what was intended? > >Assignment >... >It should be noted that the RIPE NCC only issues RIPE handles and >not other Internet handles. this is in contradiction to the first assumption!??? ____________________ I think the wording, and maybe even the thinking, has to be made a little bit clearer (at least to me :-) I'm reading the proposal to mean the following: - On a global scale, we need unique handles (Internet Handles). - InterNIC doesn't provide them for use by Regional Registries - There is an agreement that Internet Handles are manufactured in a distributed way by appending the Regional Registry code - It doesn' matter from where I get the handle, it is an Intenet Handle that is globally unique and valid. (ie. I can get my person object registered in any database other than the RIPE-DB with my RIPE-assigned Internet Handle) **correct?? - we have to get this going by a) converting all existing handles, which have by definition been assigned by the InterNIC into the -INIC format/syntax b) assign -RIPE format/syntax handles for all the others in the RIPE-DB - to keep it going we refuse person objects, that do neither come with an Internet Handle, nor request assignment by the agreed string of "assign" Anything wrong with this? Wilfried (WW144-INIC :-)

2 1

RIPE Handle document
by Marten Terpstra 07 Dec '93

07 Dec '93

Folks, Please find below the draft document to implement RIPE handles in the RIPE database. Please read it carefully, since it will impact registration of people. Current timescales: from draft to official document: Dec 13th (1 week from now) implementation: Dec 20th (2 weeks from now) Comments please. -Marten Internet Handles and the RIPE Database Daniel Karrenberg Marten Terpstra Document ID: ripe-nh ABSTRACT This document describes the need for unique iden- tifiers for Persons and the way they are assigned and used in the RIPE database. Why Internet Handles Like other registry databases the RIPE Network Management Database [ripe-013] stores information about contact persons for various other object types stored in the database such as network numbers, DNS domains and autonomous systems. Data about each contact person is stored in a "person" object which in turn is referenced by the other objects. This way data about a real person is stored only in one place, the person object. This has the advantage that any necessary changes need to be done only in one place rather than in each object the person is a contact for. Originally each person was uniquely identified by their full name and references were implemented by storing the full person name in the contact attributes of other objects. A side effect of this was that the database could not store more than one person with the same full name. When this ("John Smith") problem became an issue another attribute was needed to disambiguate persons with the same name. Since the InterNIC was already using a "NIC Handle" scheme and it was hoped to unify the registry databases quickly these handles were used. NIC handles are unique identifiers consisting of two or three aphabetic cahracters and a serial number. A "nic-hdl" attribute was added to the person object. If present this "nic-hdl" is now used together with the "person" attribute to uniquely identify a person. The value of nic-hdl is a search key for the database and can be used to reference a contact person in the contact attributes of other objects. A side effect of this is that all persons needing a handle to ripe-nh.txt - 2 - disambiguate them from another person need to be in the InterNIC database in order to obtain a NIC handle. This was not considered a problem because quick unification of the databases was expected quickly. As it turns out the assignment of globally unique handles from a single number space is not likely to be feasible. Therefore there is a need for more local assignment of unique handles. These handles will also be used in the database exchange between regional regis- tries. The regional registries agreed to create separate handle spaces by appending a suffix identifying the registry to handles creating a unique Internet handle. This document describes the procedures to implement this in the European Regional Internet Registry. RIPE Handle Internet handles issued by the RIPE NCC are called RIPE handles. The purpose of a RIPE handle is to uniquely identify a person in the RIPE network management database and other related databases that choose to use it. A RIPE handle is a string of 2-3 letters immediately followed by a serial number without leading 0s followd by the string "-RIPE". Legal RIPE handles are: AB1-RIPE AXA123-RIPE XYZ99-RIPE Normally the letters are chosen to be the initials of the person. The -RIPE suffix is used to disctinguish RIPE-handles from Internet handles issued by other registries. Internet handles issued by the InterNIC in the RIPE database will be suffixed by the string "-INIC" to distinguish them from other handles. All persons in the RIPE database must have an Internet handle. Every person in any of the databases keeping contact information should only use Internet handle. Assignment RIPE handles are assigned by sending a person object to the normal update address <auto-dbm(a)ripe.net> with "nic-hdl" value of "assign". The update process will then generate a unique handle, insert the person object with the new handle in the database and report back the handle. In case there already are persons with the same full name in the database the update process will include them in the ripe-nh.txt - 3 - report so that the user can check whether he inadvertently created a duplicate person object. Users wishing to obtain a specific RIPE handle (vanity handle) can request that by specifying it after the "assign" string, e.g. "assign JB007-RIPE". If the handle in question is available it will be assigned. It should be noted that the RIPE NCC only issues RIPE handles and not other Internet handles. Usage The primary use of RIPE handles is to reference a specific person in the RIPE database, either in another object or a database query. Contact attributes can have the following types of values: John E. Doe full name not recommended AXA123-RIPE Internet Handle John E. Doe (JED12) full name (handle) recommended Wherever possible the use of full names on their own should be dis- continued. These references can become ambiguous unnoticedly at any time by another person with the same name being registered. The handle plus full name syntax is recommended because it makes it possible to detect typing errors in handles. Handles can also be used when querying the RIPE whois server. Matches will occur for either the full handle (AXA123-RIPE) or just the part before the suffix (AXA123). In the latter case all persons in the queried databases with a handle starting in AXA123 will match. Transition For the database exchange with the InterNIC it is neccessary for each person in the RIPE database to have a unique Internet handle. Therefore the NCC will assign a RIPE handle to each person without a NIC handle in the database on the 20th of December 1993. >From that point this handle must be included in any updates made to that person entry. The handle should be used in all references to a person in other database object. For the conversion of local databases the RIPE NCC will provide local registries and other interested parties with a tool which adds ripe-nh.txt - 4 - RIPE handles to persons in database objects. The tool will accept RIPE database formatted input files without syntax checking and will output the file unchanged but with handles added. The tool queries the RIPE database and can thus be run only after handles have been added to the RIPE database. Becuause there is no syntax checking the tool should work for databases with local attributes or objects as long as they adhere to the general RIPE database format. ripe-nh.txt

5 7

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

RE: DB Minutes
by Wilfried Woeber, UniVie/ACOnet 01 Oct '93

01 Oct '93

>I propose to add the text below to the DB minutes: Good idea. I think the example 2 should be corrected. See below. ---- |In case two or more guardians want to set an attribute |which can only have one value, the current state of the |attribute will not be changed and all guardians concerned will |be notified. | |Example: | |The aut-sys attribute of network 193.193.193.0 in the database is AS193. |AS4711 adds this network to his guardian file. At the next database cleanup |all guardian files will be examined. | | 1) if the AS193 guardian file still contains 193.193.193.0 a conflict | exists and the cuurent database state prevails: AS193 will remain | | 2) if 193.193.193.0 has been removed from the AS193 guardian file | no conflict exists and AS193 will be replaced by AS4711 ^^^^^^ |Similarly the aut-sys attribute will remain undefined if it is undefined |and two guardians add it simultaneouly. | |Since the cleanup runs every 24 hours guardians involved in a change should |coordinate their changes such that they are done in the same 24h period. | ---- >clear? Yes, Sir! :-) Wilfried.

2 1

DB Minutes
by Daniel Karrenberg 01 Oct '93

01 Oct '93

The routing wg posed the question "how will a conflict between two guardians be resolved?". To my recollection this was discussed briefly in the DB WG but not minuted (my fault). I propose to add the text below to the DB minutes: ---- In case two or more guardians want to set an attribute which can only have one value, the current state of the attribute will not be changed and all guardians concerned will be notified. Example: The aut-sys attribute of network 193.193.193.0 in the database is AS193. AS4711 adds this network to his guardian file. At the next database cleanup all guardian files will be examined. 1) if the AS193 guardian file still contains 193.193.193.0 a conflict exists and the cuurent database state prevails: AS193 will remain 2) if 193.193.193.0 has been removed from the AS193 guardian file no confluict exists and AS193 will be replaced by AS193 Similarly the aut-sys attribute will remain undefined if it is undefined and two guardians add it simultaneouly. Since the cleanup runs every 24 hours guardians involved in a change should coordinate their changes such that they are done in the same 24h period. ---- clear?

1 0

Database beta: Bug in enkeys.pl
by Daniel Karrenberg 28 Sep '93

28 Sep '93

Gabor Kiss <kissg(a)sztaki.hu> found a bug in enkeys.pl. His fix is included below. It has been incorporated in the beta release. Future announcements like this will only be made to the list <db-beta(a)ripe.net>. Be sure to get on this list if you use the beta release. Daniel *** /tmp/T0a09361 Tue Sep 28 17:40:00 1993 --- enkeys.pl Tue Sep 28 17:17:28 1993 *************** *** 1,9 **** # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.13 $ ! # $Author: marten $ ! # $Date: 1993/08/19 14:53:37 $ # require "misc.pl"; --- 1,9 ---- # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.14 $ ! # $Author: dfk $ ! # $Date: 1993/09/28 16:16:57 $ # require "misc.pl"; *************** *** 39,45 **** $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); } --- 39,45 ---- $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9\-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); }

1 0

Beta RIPE database software
by Marten Terpstra 27 Sep '93

27 Sep '93

folks, I have made a beta database distribution for you all, with the emphasis on BETA. I just packed all the sources and stuff together, documentation and manual pages have not been updated to include all the changes we made over the last weeks, so this is "as is". A "real" distribution will follow whenever I am back in November, or Daniel may make one before that. You can find it on: ncc.ripe.net:/dbase-beta/dbase-beta.tar.Z NOTE this is NOT on ftp.ripe.net. The directory dbase-beta is NOT readable, but the dist can be fetched anyway. Have fun, -Marten

2 1

Re: Obsoleting "connect"
by Wilfried Woeber, UniVie/ACOnet 24 Sep '93

24 Sep '93

Folks, sorry for being late to voice my opinion, but I'm again out of office. BTW, I'm glad that Helsinki University provides my with decent access to the Internet! *> I tend to agree with you here but before we change the database config to *> make connect optional I guess we should get the okay from the chair who *> will be coordinating the new definitions for the objects. * *I agree. It is my understanding that this approach was a general consensus, thus I propose to (immediately) proceed in this direction. *> Also, we can take it a step further in that if the connect field is there *> it is LOCAL (something to add to the syntax checker ;-(). * *I was thinking of a multi-step phase-in of the new policy, and that this *would be the natural next step. Or do we just jump into it with both feet *rigt away? Well, sometimes you have to jump, although in this case I would strongly advocate a step-by-step approach. I'd also like to keep the possibility of submitting objects with connect: attributes other than LOCAL, as long as we have not agreed on and implemented a decent replacement functionality. More so if the attribute is optional, I don't see the case for doing more syntax checking for an attribute that is about to go away. I include the relevant section of the DB-WG minutes FYI. I think the wording does reflect the proposed approach reasonably well: ---------- 6. DB usage conventions and recommendations Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion. However, there is a need for the functionality, maybe the community: approach is the right way to go (eg. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting. ---------- Wilfried.

3 2

Guarded Objects are now better protected
by Daniel Karrenberg 24 Sep '93

24 Sep '93

Dear colleagues, A recent accident has caused us to protect the guarded objects in the database a little better before the maintainer attribute is fully implemented. Guarded objects can from now on only be updated thru the manual procedure which involves plausibility checking by NCC staff. The manual procedure uses the old mailbox ripe-dbm(a)ripe.net. Any updates for guarded objects sent to the auto-dbm(a)ripe.net mailbox will be refused with the error message: *ERROR*: guarded objects cannot be updated via automatic procedure If you get such an error, re-send the update to ripe-dbm. Once the maintainer attribute is implemented authorisation will be handled automatically. Daniel PS: We hope to have the update procedure for guarded *attributes* deployed next week.

1 0

Obsoleting "connect"
by Havard Eidnes 23 Sep '93

23 Sep '93

Hi, if my memory serves me well, I think the RIPE DB working group concluded to restrict the legal values for the "connect" field to only "LOCAL", and if wider connectivity for a net has been established to not use this attribute in the objects in the database. However, this is somewhat at odds with the current definition of the connect field in the inetnum template, where the attribute is mandatory. So what do you put in an object which has wider connectivity than internal to the "home" autonomous system? My proposal to progress this decision (as mentioned at the end of the RIPE meeting) is thus to initially demote the "connect" attribute from mandatory to optional, and later add stricter checks in the RIPE database software for the values of the connect attribute. Currently updates missing the connect field are being bounced (I know, I tried it while I was at the RIPE meeting :-) - Havard

1 0

Minutes RIPE #16, DB Working Group
by Wilfried Woeber, UniVie/ACOnet 22 Sep '93

22 Sep '93

Dear all, I just recently submitted the draft minutes for the DB-WG meeting (jointly produced by Daniel am me) to Anne. Any comments welcome! Wilfried. ---------------------------------------------------------------------- Report from the Database-WG Meeting at the 16th RIPE Meeting, Amsterdam ----------------------------------------------------------------------- 0. Additions to/modifications of the agenda The proposed agenda was accepted. 1. The new Database Software Marten Terpstra provided a detailed report on the current state of the DB-Software, both from a software point of view as well as from the deployment point of view. The slides for this presentation can be found in the presentations directory in the RIPE document store: ftp.ripe.net:ripe/presentations The new software is in production use since Friday September 10th and until now there have not been any major problems. During the discussion it was again stressed, that the current implementation is built to do syntax checks according to the object description and not according to common usage practice. The RIPE NCC welcomes suggestions as to where the syntax checking needs to be changed. Currently objects with illegal schema are deleted from the database. One of the things discussed was how to avoid a possibly large number of bounced submissions. One way of doing this is to obtain (part of) the new software to do the checking locally. The beta-version of the software is available, although it probably makes more sense to wait for the official software distribution which will provide a dedicated syntax-checker. A syntax checker daemon at the NCC was also suggested to remove the requirement to run the software locally. A template generator was suggested as well. This needs more discussion on the mailing list. The NCC has run a syntax check on the whole database and was asked to make the syntax error output available. Daniel Karrenberg gave an overview on the "Authorization and Notification of Changes in the RIPE-DB" proposal. It was decided to implement it as proposed. Proposals on how to better support the distribution of the update process are very welcome. The discussion of implementing "guarded attributes" revealed concern about the possibility to delete an object that has a guarded attribute. It was agreed that the implementation will not delete any object as long as guarded fields are present. This will force removal of guarded fields from the object before the delete operation is accepted. The database is NOT keeping track of "pending deletes", thus the delete request has to be submitted again after removal of the guarded attribute(s). The NCC will look into ways to notify guardians of failed deletes. The originator of the delete request will of course be notified. The procedure to convert existing information into guarded information (eg. aut-sys: for the network object) was agreed as follows: - the NCC moves the information from the database to the guardian files - initially the NCC is the guardian - as soon as possible, responsibility for the files is transferred to the real guardian(s) 2. Database (and Software) Documentation The documentation will be structured to consist of - Object Definitions and general background information, by WW and NCC and available before the end of 1993 - Software Documentation, provided by the NCC asap - Maintainer's Guide (for eg. the Local-IRs) additional input and support is expected from the Local-IRs and others - Secondary Server Guide additional input and support is expected from the Local-IRs and others The Objects Definition and the SW-Documentation get priority, in the listed order. 3. Unique Person Handles Given the growth of the database, it is urgent to distinguish person objects for people with the same name! After another round of thorough discussion it was decided that RIPE suggests a global scheme to the InterNIC. One of the possible solutions is to reserve a sub-range of the NIC handle space for RIPE allocation, eg. XY3000-XY5000. If this approach fails, then WW and the NCC will propose a unique identifier scheme for RIPE (aka "RIPE Handle"). 4. Objects Review and Proposals The proposed CLNS routing object (dom-prefix:) was presented by Henk Steenman and accepted. Some minor loose ends how to check for syntax and maybe semantics of the hexadecimal strings that are the CLNS address-prefixes have to be ironed out (Henk Steenman and Tony Bates). The long-standing proposal to build a "Resource Object" was formally withdrawn. Then the discussion moved on to agree on how to make a smooth transition from ripe-60 to the ripe-81 format to describe the routing. The steps are as follows: - as soon as the guarded fields are implemented, ripe-60 entries will no longer be accepted. - ripe-60 information is converted to ripe-81 format. - when there are no longer any operational dependencies then all ripe-60 data will be removed from the database. Jean-Michel Jouanigot is the focal point for the ripe-60 --> ripe-81 transition coordination. Also the gateway: field for the network objects was confirmed to be obsolete and can be removed from the databse. 5. DB Exchange format(s) and procedures The circulated document about the agreed interchange format was briefly reviewed. Everything seems to be in place to actually start exchanges with the InterNIC. There was consensus that this has a very high priority. Currently the recommendation is not to try to get the various databases in sync manually. 6. DB usage conventions and recommendations Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion. However, there is a need for the functionality, maybe the community: approach is the right way to go (eg. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting. 7. whois++ by Peter Deutsch et.al. The whois++ project was briefly mentioned, although the DB group had too little information to actually discuss the issue. AOB It was mentioned that there is a need for new tools to support the Local-IRs. This needs more discussion on the e-mail list. Action-List: ------------ Action 16.?: NCC Put together a consolidated distribution of the new DB software, including a separate syntax checker for objects Action 16.?: Wilfried Woeber Start discussion on the DB mailing list on new tools needed, eg. template generator, syntax checker daemon at the NCC... Action 16.?: NCC Make the error reports form the DB syntax check publicly available Action 16.?: NCC Implement changes to DB procedures according to the proposal "Authorization and Notification of Changes in the RIPE-DB" by Daniel Karrenberg Action 16.?: NCC Implement changes to DB procedures for the guarded attributes according to the agreement Action 16.?: Wilfried Woeber and NCC Produce documentation about "Background, History and Object Definitions" for the new database software before the end of 1993 Action 16.?: NCC Produce "Software Documentation" for the new databse software asap Action 16.?: NCC To approach the InterNIC to agree on the use of a sub-range of the global NIC-Handle space for RIPE usage Action 16.?: Henk Steenman and NCC (Tony Bates) Implement the dom-prefix: object for CLNS routing, after tightening the syntax definition and semantics of the CLNS-address hexadecimal string Action 16.?: Jean-Michel Jouanigot To coordinate the transition from ripe-60 to ripe-81 format for routing description Action 16.?: NCC Try to actually get the synchronisation of the various databases going, using the recently agreed DB Exchange Format Action 16.?: NCC Start discussion on the mailing list by providing a first proposal how the functionality of the badly defined connect: attribute could be replaced (with the target group of the end-user in mind!) by using eg. community: and other forthcoming tools from the PRIDE project ----------------------------------------------------------------------

2 1

Slides of the RR status
by Tony Bates 20 Sep '93

20 Sep '93

please note - as asked the slides I presented at the Routing working group session of the status of the RIPE RR are available from ftp.ripe.net:ripe/presentations/ripe-m16-tony-RRSTATS.ps.Z plus various other slides of possible relevence (i.e plenary talks and Marten's database presentation). All presentations are in the ripe/presentations directory. --Tony. The following are already availabel from the 16th RIPE meeting. ripe-m16-dfk-NCC-REPORT.ps.Z ripe-m16-marten-DBDETAILS.ps.Z ripe-m16-marten-DBPLEN.ps.Z ripe-m16-tony-GISSREP.ps.Z ripe-m16-tony-PRIDE.ps.Z ripe-m16-tony-RRSTATS.ps.Z ripe-m16-tony-RSREP.ps.Z

1 0