Re: Unique NIC/RIPE/xxx-Handles
| * Given that one of the aims of handles is (I think !) a more | * compact, shorthand form of referring to someone, the RIPE-DR222 | * idea sounds better to me - DR222@rs.internic.net is longer than | * my real name ! | |I have to agree here. I think a nice syntax would be: | |<NIC>-XXXYYY | |where it is probably is too much hastle to ask InterNIC to redo all their |nic-hdls to have INTERNIC-XXXYYY, so they probably keep the handles without |the NIC. The others could be: | |RIPE-MT2 |APNIC-MT2 |... My original reasoning was something like: Keep the InterNIC-Handles as they are, ie. when there is no NIC-ID, then let's assume it is InterNIC. For the others, tag them. For the DataBase, store everything without a (external) tag with an (internal) InterNIC tag. Also, I think it is really not necessary - maybe not even useful? - for people to obtain more than one handle. However if someone is hit by that, or even wants it :-), we could probably live (DataBase-wise) with a definition of (REQUIRED, MULTIPLE, UNIQUE). (Marten: could the DB-SW digest this?) |Question is, to what level do we go down for the NIC ? Should we go down to | |DENIC-MT2 |JANET-MT2 | |I don;t think so. My sense of NIC for the handles should be the highest level |IP number authorities in the area .... (ie continents) I think the question is, by whom and where these handles are dished out. My personal preference is to have this done at the highest possible level, ie. RIPE-NCC, APNIC, etc... Unfortunately, until now there have not been any contributions to this aspects. Regards, Wilfried.
"Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes * | * Given that one of the aims of handles is (I think !) a more * | * compact, shorthand form of referring to someone, the RIPE-DR222 * | * idea sounds better to me - DR222@rs.internic.net is longer than * | * my real name ! * | * |I have to agree here. I think a nice syntax would be: * | * |<NIC>-XXXYYY * | * |where it is probably is too much hastle to ask InterNIC to redo all their * |nic-hdls to have INTERNIC-XXXYYY, so they probably keep the handles without * |the NIC. The others could be: * | * |RIPE-MT2 * |APNIC-MT2 * |... * * My original reasoning was something like: * * Keep the InterNIC-Handles as they are, ie. when there is no NIC-ID, then * let's assume it is InterNIC. For the others, tag them. For the DataBase, * store everything without a (external) tag with an (internal) InterNIC tag. * * Also, I think it is really not necessary - maybe not even useful? - for * people to obtain more than one handle. However if someone is hit by that, o * r * even wants it :-), we could probably live (DataBase-wise) with a definition * of (REQUIRED, MULTIPLE, UNIQUE). * (Marten: could the DB-SW digest this?) The thing that is tricky here is that the combination of name and nic handle is used as the unique key for a person, and these fields cannot be multiple because then I cannot guarentee the ordering of the unique key any longer. What I mean is say I have two handles: person: Marten Terpstra nic-hdl: MT2 nic-hdl: RIPE-MT2 The unique key could then be: "Marten Terpstra\tMT2\tRIPE-MT2" and "Marten Terpstra\tRIPE-MT2\tMT2" which are different unique keys for the same person, which gets me into trouble. On second thought, with the new software: person: Marten Terpstra address: RIPE NCC address: Kruislaan and person: Marten Terpstra address: Kruislaan address: RIPE NCC are different objects, and if the unique keys are the same, this will cause an update. (Am I still making sense ?) Inside an attribute the ordering does matter .... (These are the sort of things that come up implementing all this stuff) The more I think about it, the more I like the idea I said in my last mail, ie same global nic handle space, just divide the numbers that go with the initials ... -Marten
participants (2)
-
Marten Terpstra -
Wilfried Woeber, UniVie/ACOnet