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.
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. 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? --asp@uunet.uu.net (Andrew Partan)
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?
Give him/her a handle that is unique within that local registry based on his/her first letter of each word in a name with a some number if more that one occurence exists. This can be then globalized by post-fixing a unique "registry id". We currently have a set of "registry-ids" internally for the swip project that we can dole out to local registries. -Mark
Give him/her a handle that is unique within that local registry based on his/her first letter of each word in a name with a some number if more that one occurence exists.
Or some variation... JPNIC currently has a fixed length: 2 characters followed by 3 numbers with JP appended, e.g. mine is DC002JP. The actual implementation of the local part is, of course, a local issue.
This can be then globalized by post-fixing a unique "registry id". We currently have a set of "registry-ids" internally for the swip project that we can dole out to local registries.
How are people going to resolve the registry-ids into a host to query? -drc
David R Conrad <davidc@iij.ad.jp> writes:
This can be then globalized by post-fixing a unique "registry id". We currently have a set of "registry-ids" internally for the swip project that we can dole out to local registries.
How are people going to resolve the registry-ids into a host to query?
The goal of all Internet registries (and the swip project) is to enable all whois servers at the registries to resolve any query. Currently we want to achieve this by simply exchanging the databases. I would expect the APNIC to join the database exchange. If we need something more sophisticated we can build it into the servers at a later stage. Daniel
* 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. Andrew is right here. One person, one nic-handle. We have been talking about the way to introduce this, and we came up with something along the lines of: - no flag day, ie no day where we assign everyone in the database a handle - assign handles where there are conflicts using the new scheme - assign nic handles on request (by sending in a person with nic-handle: assign) * 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. That is on my list now. I will write some script to find all possible and real conflicts currently in the database. Our guess is that it is not that many today. These have to solved by manually. -Marten
participants (6)
-
asp＠uunet.uu.net -
Daniel Karrenberg -
David R Conrad -
Erik-Jan.Bos＠SURFnet.nl -
markk＠internic.net -
Marten Terpstra