Hi, Object reordering only takes place when the mail contains AUTO nic-handle creation. This is because references to the new object need to be resolved (by creating the nic handle) before the other objects can be processed. If you don't request AUTO nic handle creation, there is no reordering. Therefore, sending a mail containing a delete followed by a creation should be safe (the only possibility for it to go wrong would be if between the processing of the deletion and the creation an update taking place at the same time grabs the old nic handle. This is extremely unlikely and impossible to do on purpose since it depends on machine load, etc). Once again, if the object in the deletion is referred to by other DB objects the deletion will fail. But in this case, so would the creation immediately after it, since the nic handle would be in use. regards, Joao "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes: * >you're right - it's possible this way if the person object isn't * >related to any other object in the database. FMPOV it should be * >strongly recommended that deletion and re-creation would be done * >by just _one_ email to 'auto-dbm@...' because of the sequential * >processing. This avoids the re-use of the NIC-handle by the * >'AUTO-1' mechanism in between two separate mails. * * This is also my "gut-feeling". * * However doing so in many cases generates "funny" error messages * due to object re-ordering within a single update message, and it * might interfere with what you had in mind. * * I think this is still not resolved completely. * Maybe the DB SW technicians could clarify this issue? * * Wilfried. *
On Mon, Dec 28, 1998 at 06:01:38PM +0100, Joao Luis Silva Damas wrote:
Hi,
Therefore, sending a mail containing a delete followed by a creation should be safe (the only possibility for it to go wrong would be if between the processing of the deletion and the creation an update taking place at the same time grabs the old nic handle. This is extremely unlikely and impossible to do on purpose since it depends on machine load, etc).
It is not extremely unlikely as handles are reused immediately after deletion. To my knowledge the handle with the smallest number is assigned to new persons, so the only constraint to be met is that the initials are the same.
Once again, if the object in the deletion is referred to by other DB objects the deletion will fail. But in this case, so would the creation immediately after it, since the nic handle would be in use.
Are you sure that this feature is enabled on the 'production system' ? -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
Michael van Elst <mlelstv@xlink.net> writes: * On Mon, Dec 28, 1998 at 06:01:38PM +0100, Joao Luis Silva Damas wrote: * > Hi, * > * > Therefore, sending a mail containing a delete followed by a creation shoul * d be * > safe (the * > only possibility for it to go wrong would be if between the processing of * the * > deletion and the creation an * > update taking place at the same time grabs the old nic handle. This is * > extremely unlikely and impossible to do on purpose since it depends on mac * hine * > load, etc). * * It is not extremely unlikely as handles are reused immediately after * deletion. To my knowledge the handle with the smallest number is * assigned to new persons, so the only constraint to be met is that * the initials are the same. * It is unlikely if you do the delete and the creation in the same mail (specially if these are the only two items in the mail). Even with nic handle reuse, the "impersonator" request must get in between the processing of your deletion and the creation of the new object (normally less than a second if both are in the same mail). May be nic handle reuse would be something to talk about in RIPE 32 during the db-wg meeting, Wilfried ? * * > Once again, if the object in the deletion is referred to by other DB objec * ts * > the deletion will fail. But in this case, so would the creation immediatel * y * > after it, since the nic handle would be in use. * * Are you sure that this feature is enabled on the 'production system' ? Pretty sure. See example below: ***** Start example ***** Part of your update FAILED
From: Joao Luis Silva Damas <joao@ripe.net> Subject: Date: Tue, 29 Dec 1998 10:32:22 +0100 Msg-Id: <199812290932.KAA02188@x41.ripe.net>
For help see <http://www.ripe.net/db/> or include 'help' in the subject line of your message Objects without errors have been processed. Delete FAILED: [person] JLSD1-RIPE (Joao Luis Silva Damas) person: Joao Luis Silva Damas address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 e-mail: joao@ripe.net nic-hdl: JLSD1-RIPE notify: joao@ripe.net changed: roderik@ripe.net 19970926 source: RIPE *ERROR*: Object still referenced by: *ERROR*: 1 mntner object *ERROR*: 1 role object *ERROR*: cannot delete object that is still referenced *ERROR*: by other objects in the database ****** End Example ***** Regards, Joao
Joao Luis Silva Damas <joao@ripe.net> writes:
May be nic handle reuse would be something to talk about in RIPE 32 during the db-wg meeting, Wilfried ?
Definitely seconded. My proposal: Do not re-use handles at all. This prevents a lot of problems and also makes the references unique *over time*. This makes questions of the form: "Who have the administrative contacts of this inetnum since 1995?" *much* easier to answer quickly. Daniel
Daniel Karrenberg wrote:
Joao Luis Silva Damas <joao@ripe.net> writes: May be nic handle reuse would be something to talk about in RIPE 32 during the db-wg meeting, Wilfried ?
Definitely seconded. My proposal: Do not re-use handles at all. This prevents a lot of problems and also makes the references unique *over time*. This makes questions of the form: "Who have the administrative contacts of this inetnum since 1995?" *much* easier to answer quickly.
Is that wise? See the InterNIC and handles... A handle should not be reused within a certain period of time (days, weeks?), but a reuse should most certainly be possible. Otherwise we may end up with something like ns84986-ripe or something. It is not that bad yet, of course, but it will come...? I can only speak for myself, but I do look for ppl already having a handle and see if it reusable or referenced somewhere else when transferring a domain to us. As long as some still do that, reusing is a nice-to-have option. Or what do you mean by saying "reuse" ? Regards, Alexander Koch -- SGH Internet Division, Alexander Koch, Systems Administration Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307
Hi there, Alexander Koch schrieb:
Daniel Karrenberg wrote:
Joao Luis Silva Damas <joao@ripe.net> writes: May be nic handle reuse would be something to talk about in RIPE 32 during the db-wg meeting, Wilfried ?
Definitely seconded. My proposal: Do not re-use handles at all. This prevents a lot of problems and also makes the references unique *over time*. This makes questions of the form: "Who have the administrative contacts of this inetnum since 1995?" *much* easier to answer quickly.
Is that wise? See the InterNIC and handles... A handle should not be reused within a certain period of time (days, weeks?), but a reuse should most certainly be possible. Otherwise we may end up with something like ns84986-ripe or something. It is
it will come, with or withour reuse - in any way :) We'd better talk about a system that does not overrun or produces handles like "ns84986".
not that bad yet, of course, but it will come...?
I can only speak for myself, but I do look for ppl already having a handle and see if it reusable or referenced somewhere else when transferring a domain to us. As long as some still do that, reusing is a nice-to-have option.
Or what do you mean by saying "reuse" ?
Regards, Alexander Koch
-- SGH Internet Division, Alexander Koch, Systems Administration Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307
With best regards ________________________________ InternetX GmbH, Domain Service Center Curd Bems, hostmaster@internetx.de Tel. +49 941 5839458 Fax. 5839460
Alexander Koch <akoch@sgh-net.de> writes:
Is that wise? See the InterNIC and handles...
What I mean is that a handle lives as long as the object it identifies. If the object is deleted that handle is not reused to identify a different object. I used to believe that high numbers in handles should be avoided and handles could be re-used. In the light of various problems and the "history" questions I referred to, I now believe that handles should not be re-used. Daniel
Daniel wrote: [snip]
What I mean is that a handle lives as long as the object it identifies. If the object is deleted that handle is not reused to identify a different object.
So the handle is deleted if it's only referenced in *this* (also deleted) certain object? And the handle itself (XY123-RIPE) will not be used again, right? Not much harm, but not needed, IMO.
I used to believe that high numbers in handles should be avoided and handles could be re-used. In the light of various problems and the "history" questions I referred to, I now believe that handles should not be re-used.
I think having a certain period of time will help sufficiently in this case. If a handle is *deleted*, half a year after its deletion there is no big risk, I would say. Since deletion will not happen if the handle is still referenced (!) and connecting a domain (DENIC) will not happen if the handle does not exist... Regards, Alexander -- SGH Internet Division, Alexander Koch, Systems Administration Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307
> What I mean is that a handle lives as long as the object it identifies. > If the object is deleted that handle is not reused to identify a > different object. So the handle is deleted if it's only referenced in *this* (also deleted) certain object? And the handle itself (XY123-RIPE) will not be used again, right? Not much harm, but not needed, IMO. I would suggest that if the handle could be referenced elsewhere then you don't delete it even if you think it's not referenced. We reference (person) objects that aren't in our DB and so having the object referenced disappear would be a really bad idea. Before someone says well don't do that consider that you have a hard enough time keeping one person object up to date and so it is better to reference this "master" object than to create another one which in time will be forgotten about. In most cases the "master" is an InterNIC handle but need not be. Mark.
Hi,
Is that wise? See the InterNIC and handles... A handle should not be reused within a certain period of time (days, weeks?), but a reuse should most certainly be possible. Otherwise we may end up with something like ns84986-ripe or something. It is not that bad yet, of course, but it will come...?
Whats the problem with CK31459-RIPE. It's only a handle. Ripe is not in the bussiness of assigning vanity license plates, handles or ip addresses. They run a database. I would prefer a clean policy on not reusing handles ever to a compilicated and error prone recycling policy. Remeber that detecting if a handle is still used seomwhere uis getting more complicated every day with the multiple distributed registries worldwide. Reusing handles is asking for trouble. Greetings Christian Kratzer Toplink -- TopLink Internet Services GmbH ck@171.2.195.in-addr.arpa Christian Kratzer http://noc.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here!
participants (7)
-
Alexander Koch -
Christian Kratzer -
Daniel Karrenberg -
Hostmaster INTERNETX -
Joao Luis Silva Damas -
Mark Prior -
Michael van Elst