From Daniel.Karrenberg at ripe.net Mon Dec 6 12:26:51 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Dec 1993 12:26:51 +0100 Subject: Document Anncouncement: Procedures for DNS Delegation in the IN-ADDR.ARPA Domain Message-ID: <9312061126.AA06588@ncc.ripe.net> # Apologies to everyone for the not completely processed version of the previous announcement. Daniel -------------- next part -------------- New/Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-105 Title: Procedures for DNS Delegation in the IN-ADDR.ARPA Domain Author: Daniel Karrenberg, Marten Terpstra Date: 6 December 1993 Format: PS=33719 TXT=11597 Bytes Obsoletes: ripe-85 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the procedures for the delegation of zones in European subdomains of IN-ADDR.ARPA. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-docs" followed by the command "get filename". The relevant filenames for this document are: ripe-105.txt for the ASCII version ripe-105.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document. -------------- next part -------------- SEND ripe/docs/ripe-docs/ripe-105.txt From Marten.Terpstra at ripe.net Mon Dec 6 13:08:22 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 06 Dec 1993 13:08:22 +0100 Subject: RIPE Handle document Message-ID: <9312061208.AA06747@ncc.ripe.net> 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 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 From Daniel.Karrenberg at ripe.net Mon Dec 6 12:23:39 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Dec 1993 12:23:39 +0100 Subject: Document Announcement: IP Address Space Assignment Procedures Message-ID: <9312061123.AA06570@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-104 Title: IP Address Space Assignment Procedures Author: Daniel Karrenberg, Marten Terpstra Date: 6 December 1993 Format: PS=29433 TXT=9761 Bytes Obsoletes: ripe-72 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the procedures for the assignment of IP address space by European local Internet Registries. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-docs" followed by the command "get filename". The relevant filenames for this document are: ripe-104.txt for the ASCII version ripe-104.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document. -------------- next part -------------- SEND ripe/docs/ripe-docs/ripe-104.txt From Piet.Beertema at cwi.nl Tue Dec 7 11:32:43 1993 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 07 Dec 1993 11:32:43 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Mon, 06 Dec 1993 13:08:22 +0100 . <9312061208.AA06747@ncc.ripe.net> Message-ID: <9312071032.AA04033=piet@kraai.cwi.nl> 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) The latter is fine IFF it doesn't imply that from Dec 20 on the RIPE handle field is mandatory. Otherwise it's the worst time for introducing such a change and you should really postpone it to early January. Piet From mnorris at dalkey.hea.ie Tue Dec 7 15:08:50 1993 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 07 Dec 93 14:08:50 +0000 Subject: RIPE Handle document In-Reply-To: Your message of "Mon, 06 Dec 93 13:08:22 +0100." <9312061208.AA06747@ncc.ripe.net> Message-ID: <9312071408.AA21143@dalkey.hea.ie> Marten and Daniel thanks for the draft of ripe-nh. The document is, as usual, well written and easy to understand - even by me ;-) The assignment and transition procedures also look good - well done! I've spotted a few typos and suggested some minor textual changes as follows: ---------------------------------------8<--------------------------- >Why Internet Handles > >Like other registry databases the RIPE Network Management Database add a comma ----> , >[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 ... is stored in only one place ... >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. ... in each object for which the person is a contact. >Originally each person was uniquely identified by their full name ... by his 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 *********** not really a side effect, more a consequence. >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 The word "disambiguate is not in my dictionary. Even if it was, it would not be le mot juste, as the root "ambi" means "both" and you really mean "more than one". I suggest "correctly to identify" or some such. >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 ... to identify a person uniquely. >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 *********** Again, is it a side effect or a direct consequence? >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 delete ---> ***** >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 Again, a split infinitive; try "to identify a person uniquely." >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 spelling ---> ************ >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 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 >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 ** I thought leading zeroes were to be stripped (see under Ripe Handle above) >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. Will the suffix -INIC be appended to all existing non-null handles at the same time? If so, perhaps say so. > >>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 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 spelling ---> ******** >the tool should work for databases with local attributes or objects >as long as they adhere to the general RIPE database format. > Cheers. Mike From bonito at nis.garr.it Tue Dec 7 16:08:30 1993 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Tue, 7 Dec 93 16:08:30 MET Subject: RIPE Handle document In-Reply-To: <9312061208.AA06747@ncc.ripe.net>; from "Marten Terpstra" at Dec 6, 93 1:08 pm Message-ID: <9312071508.AA09492@jolly.nis.garr.it> Marten writes: > 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. I think that starting from this reasoning: > The regional registries agreed to create separate handle spaces by > appending a suffix identifying the registry to handles creating a > unique Internet handle. A method should be proposed: - either to further delegate the creation of Internet handles to local registries, in particular to national registries (registry of last resort is the actual name?) - or to differentiate the database management software when it treats actual RIPE database or local registry database. This is needed because local registries often use the RIPE-NCC database software package. Otherwise local registries have two choises: 1- use (develop?) another database software 2- define some trick to postpone the actual registration of a person entry in their local database after they have received the new RIPE handle from RIPE-NCC I think it would be easier and better to define other suffixes which could be used (and accepted by the software). The local registry then simply send person entries which already contain unique handles to the NCC. BTW: Tomorrow is an holiday in Italy, so don't be surprised if I will not comment further until thursday. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 ---------- ---------- From bonito at nis.garr.it Tue Dec 7 16:42:40 1993 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Tue, 7 Dec 93 16:42:40 MET Subject: RIPE Handle document In-Reply-To: <9312071535.AA04940=piet@kraai.cwi.nl>; from "Piet Beertema" at Dec 7, 93 4:35 pm Message-ID: <9312071542.AA10340@jolly.nis.garr.it> Piet, > What is "actual RIPE database"? Lots of the info therein is > coming from local registries, in whatever format the latter > maintain their info/database. The actual database is that one with source: RIPE in its etries. > This is needed because local registries often use the RIPE-NCC database > software package. > I fail to see what this has to do with the case. And I don't > even know whether your statement is correct: some registries > may maintain their database in a "RIPE-like" format without > using the RIPE-NCC database software package. In this case they do not have problems with the RIPE handle. > I think it would be easier and better to define other suffixes which > could be used (and accepted by the software). The local registry then > simply send person entries which already contain unique handles to the NCC. > See above: a local registry may generate unique handles, but > they don't serve the purpose of uniqueness in the context > where that uniqueness is required. If an handle is unique it could be used in many different contexts, i.e. database with source: RIPE and source: SOMETHINGELSE ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 ---------- ---------- From Piet.Beertema at cwi.nl Tue Dec 7 16:35:11 1993 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 07 Dec 1993 16:35:11 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Tue, 7 Dec 93 16:08:30 MET . <9312071508.AA09492@jolly.nis.garr.it> Message-ID: <9312071535.AA04940=piet@kraai.cwi.nl> - either to further delegate the creation of Internet handles to local registries, in particular to national registries (registry of last resort is the actual name?) To what purpose? What advantage would there be in having to go to a "regional" registry instead of the central RIPE registry? It would probably only add delay. Note that the object we're talking about (Person entries) is linked to several objects (networks, domains, whatever) that are all in the RIPE database. So whereas e.g. a domain or a network number can be registered/assigned uniquely by a "regional" registry, a "binding tag" (which the RIPE handle in fact is) should be assigned by the central body, i.e. RIPE. Otherwise the registration of handles would have to be split up even further, with domain registrars, networks registrars, AS registrars, etc. all assigning their own unique handle, which within seconds would lead to conflicts. - or to differentiate the database management software when it treats actual RIPE database or local registry database. What is "actual RIPE database"? Lots of the info therein is coming from local registries, in whatever format the latter maintain their info/database. This is needed because local registries often use the RIPE-NCC database software package. I fail to see what this has to do with the case. And I don't even know whether your statement is correct: some registries may maintain their database in a "RIPE-like" format without using the RIPE-NCC database software package. Otherwise local registries have two choises: 1- use (develop?) another database software 2- define some trick to postpone the actual registration of a person entry in their local database after they have received the new RIPE handle from RIPE-NCC True, but this looks inevitable to me and it won't be solved by delegating the handle registration to "regional" registries, given the correlation with other objects, as mentioned above. I think it would be easier and better to define other suffixes which could be used (and accepted by the software). The local registry then simply send person entries which already contain unique handles to the NCC. See above: a local registry may generate unique handles, but they don't serve the purpose of uniqueness in the context where that uniqueness is required. Piet From Marten.Terpstra at ripe.net Tue Dec 7 16:40:55 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 07 Dec 1993 16:40:55 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Tue, 07 Dec 1993 16:08:30 +0700. <9312071508.AA09492@jolly.nis.garr.it> Message-ID: <9312071540.AA03036@ncc.ripe.net> bonito at nis.garr.it (Antonio_Blasco Bonito) writes * Marten writes: * > 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. * * I think that starting from this reasoning: * > The regional registries agreed to create separate handle spaces by * > appending a suffix identifying the registry to handles creating a * > unique Internet handle. * * A method should be proposed: * - either to further delegate the creation of Internet handles to local * registries, in particular to national registries (registry of last resort * is the actual name?) Well, we decided NOT to go for this model, since it would probably create more confusion than it would solve. The tricky but here was that we wanted to make things more distributed, without confusing people with regard to nic handles. If there is only a limited set of registries handing out handles, things can be overseen. Having each and every registry assign their own handles with different postfixes is a major pain for us, since we are already dealing with 50+ registries. Try and tell them all to do things right ... We will be the ones chasing after duplicate nic handles, duplicate persons, and more of these .... * - or to differentiate the database management software when it treats * actual RIPE database or local registry database. Well, that is implementation. What I have done in the software to cater for the RIPE handle creation, if added some configuration commands, and the nic handle creation and checks will ONLY be performed if certain variables are defined. In general, none of the local registries using the software will have to do nic handle creation, so by simply not configuring it, they will not see that part of the software .... * This is needed because local registries often use the RIPE-NCC database * software package. * * Otherwise local registries have two choises: * 1- use (develop?) another database software * 2- define some trick to postpone the actual registration of a person entry * in their local database after they have received the new RIPE handle * from RIPE-NCC * * I think it would be easier and better to define other suffixes which * could be used (and accepted by the software). The local registry then * simply send person entries which already contain unique handles to the NCC. It is not that difficult. If the software at the NCC assigns a RIPE handle on request, it will of course report back with the full object, including the newly assigned nic handle. It is not difficult to then forward that to your own software. Therefore I think step 2 is not that difficult ... * * BTW: Tomorrow is an holiday in Italy, so don't be surprised if I will not * comment further until thursday. From Piet.Beertema at cwi.nl Tue Dec 7 17:01:12 1993 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 07 Dec 1993 17:01:12 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Tue, 7 Dec 93 16:42:40 MET . <9312071542.AA10340@jolly.nis.garr.it> Message-ID: <9312071601.AA05002=piet@kraai.cwi.nl> See above: a local registry may generate unique handles, but they don't serve the purpose of uniqueness in the context where that uniqueness is required. If an handle is unique it could be used in many different contexts, i.e. database with source: RIPE and source: SOMETHINGELSE 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. 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. Piet From woeber at cc.univie.ac.at Tue Dec 7 17:27:05 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 07 Dec 1993 17:27:05 +0100 Subject: RIPE Handle document Message-ID: <00976AAE.C0158A80.14926@cc.univie.ac.at> 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 at CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01 at 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 ------------------------------------------------------------------------------- From kevin at nosc.ja.net Tue Dec 7 17:36:15 1993 From: kevin at nosc.ja.net (Kevin Hoadley) Date: Tue, 07 Dec 1993 16:36:15 +0000 Subject: RIPE Handle document In-Reply-To: Your message of "Tue, 07 Dec 1993 16:40:55 +0100." <9312071540.AA03036@ncc.ripe.net> Message-ID: <21548.755282175@nosc.ja.net> Marten wrote: >Well, we decided NOT to go for this model, since it would probably >create more confusion than it would solve. The tricky but here was >that we wanted to make things more distributed, without confusing >people with regard to nic handles. If there is only a limited set of >registries handing out handles, things can be overseen. Having each >and every registry assign their own handles with different postfixes >is a major pain for us, since we are already dealing with 50+ >registries. Try and tell them all to do things right ... We will be >the ones chasing after duplicate nic handles, duplicate persons, and >more of these .... I can understand these problems, however I'd also like to raise a vote for distributed assignment, preferably by assigned number ranges (with attendant guards on the RIPE DB to automatically check the ranges ?) rather than an ever expanding list of authority prefixes/suffixes. However my reasons are somewhat selfish, as I think it will difficult to fit the process of obtaining a RIPE handle from the NCC (with a possibly quite long delay depending on the network and how well the relevant mail systems are working) into the exisitng automation system I use for the UK registry ! Kevin Hoadley, JIPS NOSC. From woeber at cc.univie.ac.at Tue Dec 7 17:47:54 1993 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 07 Dec 1993 17:47:54 +0100 Subject: RIPE Handle document Message-ID: <00976AB1.A8027CC0.14928@cc.univie.ac.at> >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 :-) From Daniel.Karrenberg at ripe.net Tue Dec 7 21:46:14 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Dec 1993 21:46:14 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Tue, 07 Dec 1993 17:47:54 MET. <00976AB1.A8027CC0.14928@cc.univie.ac.at> Message-ID: <9312072046.AA03706@ncc.ripe.net> > "Wilfried Woeber, UniVie/ACOnet" writes: > > I think the wording, and maybe even the thinking, has to be made a little b > it > clearer (at least to me :-) Certainly. > > 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 tha > t > 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 assigne > d > 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? To the contrary. This is the way it should be presented. It eluded us. Thanks for setting our thinking straight. We'll post a re-worded version a.s.a.p., which will probably be Thursday because towmorrow is very full already. Daniel DK58-INIC From Piet.Beertema at cwi.nl Wed Dec 8 10:02:14 1993 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 08 Dec 1993 10:02:14 +0100 Subject: RIPE Handle document In-Reply-To: Your message of Tue, 07 Dec 1993 17:27:05 +0100 . <00976AAE.C0158A80.14926@cc.univie.ac.at> Message-ID: <9312080902.AA05966=piet@kraai.cwi.nl> 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 From Daniel.Karrenberg at ripe.net Mon Dec 20 15:35:38 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 20 Dec 1993 15:35:38 +0100 Subject: NIC Handles Message-ID: <9312201435.AA00356@ncc.ripe.net> Friends, after all the useful input from you and some more thought we have concluded that introducing the RIPE handles this year is too ambitious. So it will be January. I see two alternatives: 1) We wait until the RIPE meeting in order to discuss all the possibilities and make a firm decision. This delays introduction well into February. Database exchange with the InterNIC is also delayed until then. 2) We introduce like planned in the first week(s) of January. In order to address concerns quick and easy assignment we will operate a server for real-time assignments. If this does not solve the expected problems we can decide about local assignements at the RIPE meeting. In order not to delay database exchange with the NIC we favour option 2. About the real-time server: It will run on a special TCP port accessible only to local IRs. The server will accept a person object with "nic-hdl: assign" and immediately echo back the person object with the NIC handle or an error message. We will provide a filter "assignhandle" to go with it so you can integrate it into your own software (we will often run it in vi/emacs). We will also provide the filter mentioned in the paper which adds handles to an existing database without handles. Does anyone have real problems with option 2? Daniel From bonito at nis.garr.it Mon Dec 20 15:54:01 1993 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Mon, 20 Dec 93 15:54:01 MET Subject: NIC Handles In-Reply-To: <9312201435.AA00356@ncc.ripe.net>; from "Daniel Karrenberg" at Dec 20, 93 3:35 pm Message-ID: <9312201454.AA04042@jolly.nis.garr.it> Daniel Karrenberg writes: > > Friends, > > after all the useful input from you and some more thought we have > concluded that introducing the RIPE handles this year is too ambitious. > > So it will be January. > > I see two alternatives: > > 1) We wait until the RIPE meeting in order to discuss all the > possibilities and make a firm decision. This delays introduction well > into February. Database exchange with the InterNIC is also delayed > until then. > > 2) We introduce like planned in the first week(s) of January. In order > to address concerns quick and easy assignment we will operate a server > for real-time assignments. If this does not solve the expected problems > we can decide about local assignements at the RIPE meeting. > > In order not to delay database exchange with the NIC we favour option 2. > > About the real-time server: It will run on a special TCP port accessible > only to local IRs. The server will accept a person object with > "nic-hdl: assign" and immediately echo back the person object with the > NIC handle or an error message. We will provide a filter "assignhandle" > to go with it so you can integrate it into your own software (we will > often run it in vi/emacs). > > We will also provide the filter mentioned in the paper which adds > handles to an existing database without handles. > > Does anyone have real problems with option 2? > > Daniel > With the above proposed server and tools I see option 2 as a feasible approach. Thank you Daniel! ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 ---------- ---------- From Piet.Beertema at EU.net Mon Dec 20 16:47:57 1993 From: Piet.Beertema at EU.net (Piet.Beertema at EU.net) Date: Mon, 20 Dec 1993 16:47:57 +0100 Subject: NIC Handles In-Reply-To: Your message of Mon, 20 Dec 1993 15:35:38 +0100 . <9312201435.AA00356@ncc.ripe.net> Message-ID: <9312201547.AA19979@mcsun.EU.net> I see two alternatives: About the real-time server: It will run on a special TCP port accessible only to local IRs. The server will accept a person object with "nic-hdl: assign" and immediately echo back the person object with the NIC handle or an error message. Perfect. Does anyone have real problems with option 2? Nope, but the very first week in January may well be very hectic for a lot of people, so I'd suggest to start no earlier than the second week. Piet From mnorris at dalkey.hea.ie Tue Dec 21 10:35:05 1993 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 21 Dec 93 09:35:05 +0000 Subject: NIC Handles In-Reply-To: Your message of "Mon, 20 Dec 93 15:35:38 +0100." <9312201435.AA00356@ncc.ripe.net> Message-ID: <9312210935.AA14877@dalkey.hea.ie> Option 2 looks fine to me, Daniel. At the same time, could we have some discussion of this service at the January meeting? Cheers. Mike From Daniel.Karrenberg at ripe.net Tue Dec 21 11:04:04 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 21 Dec 1993 11:04:04 +0100 Subject: NIC Handles In-Reply-To: Your message of Tue, 21 Dec 1993 09:35:05 GMT. <9312210935.AA14877@dalkey.hea.ie> Message-ID: <9312211004.AA04019@ncc.ripe.net> > "Mike Norris" writes: > > Option 2 looks fine to me, Daniel. At the same time, could we > have some discussion of this service at the January meeting? Of course that is the intention. Daniel PS: Thanks for the new Limerick From Daniel.Karrenberg at ripe.net Fri Dec 24 14:57:00 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 24 Dec 1993 14:57:00 +0100 Subject: NCC during the end-of-year season Message-ID: <9312241357.AA06742@ncc.ripe.net> Season's greetings to everyone, The NCC will be open for service between christmas and new year. The campus here will be closed which means less heating and no catering. In the unlikely event that you want to visit us during that period you will have to make an appointment so that we can make arrangements with campus security. Because of the campus closure it is quite possible that the office will not be staffed at times. Electronic mail will be processed as usual, postal mail will not be processed and phone calls will be handled by answering machine at times. We will also conducting some LAN restructuring during the week which may cause some of our machines to be unreachable at times. We will of course keep downtime of the service machines (database, document store) to a minimum. Again all the best from the whole NCC team Daniel