- 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