From joao at ripe.net Tue Dec 1 12:42:52 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 01 Dec 1998 12:42:52 +0100 Subject: Ripe change to whois In-Reply-To: Your message of Tue, 01 Dec 1998 07:34:43 +0100. <19981201073443.A12290@nuss.hannover.sgh-net.de> References: <19981201073443.A12290@nuss.hannover.sgh-net.de> Message-ID: <199812011142.MAA10881@x41.ripe.net> Hi again, I am hearing complaints about lack of communication regarding this change in the DB. I would like to point out the following: We try to announce things as much as possible and are always looking for suggestions and ways to improve this. However, it is and will be impossible to reach all end users (we don't want to start spamming, do we?) We expect to reach people whose interaction with the DB is a bit stronger than the occasional end user. For this we have the mailing lists, the RIPE meetings and the Web site. Discussions about developments take place in RIPE meetings and mailing lists. For the people that can't attend RIPE meetings all presentations are available at the Web site. This has been so for a some time. If you are not subscribed to mailing to mailing lists there is not much we can do, other than suggest you to subscribe if you rely on the RIPE DB for your work. I don't think we should be sending mails with announcements to everyone registered in the RIPE DB. Now, in a previous mail I pointed out a few URLs regarding discussions of the referral mechanism. These, in my view, are hardly 4 light years away (more like a click away) and they are at a place where people interested are supposed to look anyway. Not only this, but discussions have been going on since then and as you can see in the archives (publicly available at our web site) details regarding the referral mechanism were being discussed in the tld-wg and db-wg lists as recently as October 6th 1998 when we were finishing the coding and changes could still be easily introduced (as they were). If people don't want to be subscribed to these lists but the work going on there is relevant to them may be it would be a good idea to, at least, make it a monthly task to overview the archives and look at the presentations given during RIPE meetings. Otherwise, how can we make sure that we reach all interested parties without spamming the rest? So, although we may have room for improvement in getting announcements to a wider audience (and we will do our best), in this particular case and the people involved, the excuse of not knowing anything about what was going on is hardly one at all. As to why the referral as is implemented makes sense or not, I will leave this to the tld community, as the interested parties, to explain. And, I want to stress this again, everything is open to change if we a consensus is reached on what is needed/wanted. Regards, Joao Alexander Koch writes: * Hello Joao. * * [snip] * > Well the purpose of the design is to give the user information about the * > parent domain if a certain domain is missing. That's also how the rest of * the * > lookups in the RIPE DB work and is also what you do when looking in the DN * S * > for contact info for a domain and you can't find it. * * Yes, sure, if I do a lookup for a single IP address I am more than happy * to get shown the next inetnum segment. * But for domains it fails to make much sense for me. How rare are the * cases in which you have to look up the domain object of de? And if you * need to, I cannot help but ask why it is not done by hand. * * inetnum and domain objects are rarely mixable when speaking of * hierarchical systems... it does not scale equally, I am afraid. * * I would like to know some reason for this change by the tld workgroup. * * > May be people now see the need for an exact matching option (there is alre * ady * > one to disable referral: -R). However if you make this the default behavio * ur * > then the purpose of the referral mechanism is defeated. * * Let us think the other way round. Make it an whois option. * Whatever, whois -L nothing.de works fine enough for me, but * it is been all but nice hearing from users something weird * happened about domains (and they were not even using the RIPE * DB itself). Nicer If I had found out reading the announcement, * nothing more. * * Regards, * Alexander Koch * * -- * SGH Internet Division, Alexander Koch, Systems Administration * Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 * -------- Logged at Tue Dec 1 13:39:01 MET 1998 --------- From akoch at sgh-net.de Tue Dec 1 07:34:43 1998 From: akoch at sgh-net.de (Alexander Koch) Date: Tue, 1 Dec 1998 07:34:43 +0100 Subject: Ripe change to whois In-Reply-To: <199811301558.QAA23219@x41.ripe.net>; from "Joao Luis Silva Damas" on Mon, 30 Nov 1998 16:58:09 +0100 References: <19981130163000.A1306@xlink.net> <199811301558.QAA23219@x41.ripe.net> Message-ID: <19981201073443.A12290@nuss.hannover.sgh-net.de> Hello Joao. [snip] > Well the purpose of the design is to give the user information about the > parent domain if a certain domain is missing. That's also how the rest of the > lookups in the RIPE DB work and is also what you do when looking in the DNS > for contact info for a domain and you can't find it. Yes, sure, if I do a lookup for a single IP address I am more than happy to get shown the next inetnum segment. But for domains it fails to make much sense for me. How rare are the cases in which you have to look up the domain object of de? And if you need to, I cannot help but ask why it is not done by hand. inetnum and domain objects are rarely mixable when speaking of hierarchical systems... it does not scale equally, I am afraid. I would like to know some reason for this change by the tld workgroup. > May be people now see the need for an exact matching option (there is already > one to disable referral: -R). However if you make this the default behaviour > then the purpose of the referral mechanism is defeated. Let us think the other way round. Make it an whois option. Whatever, whois -L nothing.de works fine enough for me, but it is been all but nice hearing from users something weird happened about domains (and they were not even using the RIPE DB itself). Nicer If I had found out reading the announcement, nothing more. Regards, Alexander Koch -- SGH Internet Division, Alexander Koch, Systems Administration Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 -------- Logged at Tue Dec 1 16:15:53 MET 1998 --------- From mlelstv at xlink.net Tue Dec 1 14:51:34 1998 From: mlelstv at xlink.net (Michael van Elst) Date: Tue, 1 Dec 1998 14:51:34 +0100 Subject: Ripe change to whois In-Reply-To: <199812011142.MAA10881@x41.ripe.net>; from Joao Luis Silva Damas on Tue, Dec 01, 1998 at 12:42:52PM +0100 References: <19981201073443.A12290@nuss.hannover.sgh-net.de> <199812011142.MAA10881@x41.ripe.net> Message-ID: <19981201145134.A5833@xlink.net> On Tue, Dec 01, 1998 at 12:42:52PM +0100, Joao Luis Silva Damas wrote: > Hi again, Hi Joao, > I am hearing complaints about lack of communication regarding this change in > the DB. > I would like to point out the following: [...] > So, although we may have room for improvement in getting announcements to a > wider audience (and we will do our best), in this particular case and the > people involved, the excuse of not knowing anything about what was going on is > hardly one at all. yeah, it's the victims fault all over again. Sorry, this 'discussion' is only wasting time. If you don't see that this sudden modification causes problems then I cannot help you. Regards, -- 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 at xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ] -------- Logged at Tue Dec 1 19:44:17 MET 1998 --------- From Niall.oReilly at ucd.ie Tue Dec 1 19:35:23 1998 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 01 Dec 1998 18:35:23 +0000 Subject: Ripe change to whois In-Reply-To: <2.2.32.19981130151444.006f4948@max.ibm.net.il> Message-ID: <0F3A00I1UUB2TP@hermes.ucd.ie> On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone who had written: > > > >As a matter of fact the referral mechanism was seen as a way for ccTLD > >administrators to include information in the Database pointing to their own > >authoritative sources of information. I can confirm that this was indeed the intention when this was first proposed in the RIPE (25, I think) DNS-WG meeting. > > * > The RIPE NCC is therefore acting according to users directives that were > > * > discussed and agreed on an open way. > > * > Yes and no, I have to say. At RIPE 31, the functionality proposed certainly appeared to me to be what had been sought. I am no longer certain that this is indeed the case. In particular, the following surprises have arisen. First, the key notion of making the referral function available per TLD at the option of the TLD registry concerned seems to have been lost. This is a fundamental element of the original concept of over two years ago. Second, the "feature" of returning the data relating to the parent domain in the case that the specified domain cannot be found seems to me to have nothing to do with referral. The referral concept has to do with re-directing the query to an authoritative whois server, not with second-guessing the intent behind the query and substituting other data which is available locally. I suggest that this "feature" be declared a bug and removed. I am sure that these technical problems are based on misunderstandings which can easily be resolved. A more significant surprise is that TLD registries, who have had no specific prior notification, now find that data about their domains is being returned in response to a class of query for which this was not formerly the case, and that they have to deal with the unexpected fallout. Niall O'Reilly IE Domain Registry at UCD Chair, RIPE TLD-WG -------- Logged at Wed Dec 2 08:04:58 MET 1998 --------- From hank at ibm.net.il Wed Dec 2 08:04:26 1998 From: hank at ibm.net.il (Hank Nussbacher) Date: Wed, 02 Dec 1998 09:04:26 +0200 Subject: Ripe change to whois Message-ID: <2.2.32.19981202070426.006eda2c@max.ibm.net.il> At 06:35 PM 12/1/98 +0000, Niall O'Reilly wrote: >On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone >who had written: > >> > >> >As a matter of fact the referral mechanism was seen as a way for ccTLD >> >administrators to include information in the Database pointing to their own >> >authoritative sources of information. > >I can confirm that this was indeed the intention when this was first proposed in >the RIPE (25, I think) DNS-WG meeting. > >> > * > The RIPE NCC is therefore acting according to users directives that were >> > * > discussed and agreed on an open way. >> > * >> > >Yes and no, I have to say. > >At RIPE 31, the functionality proposed certainly appeared to me to be what had >been sought. I am no longer certain that this is indeed the case. In particular, >the following surprises have arisen. > >First, the key notion of making the referral function available per TLD at the >option of the TLD registry concerned seems to have been lost. This is a >fundamental element of the original concept of over two years ago. > >Second, the "feature" of returning the data relating to the parent domain in the >case that the specified domain cannot be found seems to me to have nothing >to do with referral. The referral concept has to do with re-directing the query to >an authoritative whois server, not with second-guessing the intent behind the >query and substituting other data which is available locally. I suggest that this >"feature" be declared a bug and removed. > >I am sure that these technical problems are based on misunderstandings which >can easily be resolved. > >A more significant surprise is that TLD registries, who have had no specific >prior notification, now find that data about their domains is being returned in >response to a class of query for which this was not formerly the case, and that >they have to deal with the unexpected fallout. Niall, Thank you for bringing sanity to this! I am sure now that this can all be cleared up and we can all go back to what we are all doing and let RIPE continue working the way it has always done - with no hiccups, technical excellence and 3 years ahead of the USA. -Hank > > >Niall O'Reilly > >IE Domain Registry at UCD >Chair, RIPE TLD-WG > > -------- Logged at Thu Dec 3 16:20:11 MET 1998 --------- From Daniel.Karrenberg at ripe.net Thu Dec 3 16:19:24 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 03 Dec 1998 16:19:24 +0100 Subject: Domain Object Queries and Referrals (was: Ripe change to whois) In-Reply-To: Your message of Tue, 01 Dec 1998 18:35:23 GMT. <0F3A00I1UUB2TP@hermes.ucd.ie> References: <0F3A00I1UUB2TP@hermes.ucd.ie> Message-ID: <199812031519.QAA08031@kantoor.ripe.net> Folks, I have been pondering this for a day now and I conclude that there is no easy answer to this issue, i.e. it is not yes/no 1/0 black/withe in any aspect. I'll address two aspects here: process and technology. I'll then tell you what the RIPE NCC will do now. I apologise for the wordiness of this but I find no way to say it more concisely and stay civil at the same time. Process The number of regular database users is certainly measured in the thousands these days. This means is not OK any longer for Daniel or the RIPE NCC to decide what is right or wrong, or what gets implemented. Over the years we have developed a process within RIPE to develop database policy: the database working group which involves other working groups as required. Developments are discussed and announced in these fora. However it comes with a back side and that is that quick pragmatic changes are more difficult. Deciding to undo policy derived by proper process in an ad-hoc way is something the RIPE NCC has to be uncomfortable with and do only in rare exceptional cases. But it should be done when necessary and the RIPE NCC will take the responsibility when it does so. But it cannot be something one does lightly or even regularly. Technology In this particular case there are two changes that are relevant to the issue and they are inter-related. The first change is the introduction of a referral mechanism by which an object in the database can cause the query to be referred to another server. This apparently was well understood by everyone concerned, especially the fact that it is at the user's discretion whether to use this mechanism or not. A second but tightly related change is recursive resoloution of queries for domain object. This changes the database behavior on *all* domain name queries: if no object with the exact name queried exists this will search the domain name hierarchy upwards and return the first object found in this way; in other words subdomains will be stripped until a match occurs. At the time of the discussion it was explicitly noted that recursive referral will return a parent domain object for non-existing domains. This was regarded as a feature since it would return a pointer to the correct registrar with whom to register the non-existant name and we have seen that it works ;-). The reason these changes are inter-related is that without recursive querying TLD administrators will still be obliged to enter one object for each domain and all these will have the same content: a referral to the TLD whois server. With recursive querying, only one object is required and the need for regular redundant updates is eliminated. So the two changes are tightly inter-related and just switching off recursive querying will hurt those implementing referral. How to Proceed When deciding how to proceed we first had to consider whether the problems raised by a few users warranted a deviation from the process. Our conclusion in this case is positive because apparently even some of those involved in the process did not understand the proposal they agreed to. But we also do not want to make a fix that hurts those who have been waiting for this change and are abut to make use of the new functionality. So we decided to do a quick and *very* ugly fix: We will leave recursive querying active. But in the case of finding a parent domain the result will be determined by the content of the object found: if it is a referral, the query will be referred as before; if it is a normal (non-referral) object, the answer will be "no such object" as before the change. While addressing the problems raised by a few users this will not hurt those planning to use referral based on recursive querying. Anyone with half a background in computer science and anyone with a bit of intelligence will tell us that name scoping dependent on content of the object named is a bad idea. We agree! This is why this fix will only be kept up until the next RIPE meeting when the proper process can determine the permanent soloution. If the database WG can ome to a conclusive decision before the RIPE meeting we will implement it earlier. We also do not expect to modify this fix further based on anything other than a decision based on proper process. We will also set up a special announcement list via which those not participating in the policy developemnt process can be notified of changes. Kind regards Daniel Karrenberg RIPE NCC Manager -------- Logged at Mon Dec 7 20:08:56 MET 1998 --------- From joao at ripe.net Mon Dec 7 20:07:26 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 07 Dec 1998 20:07:26 +0100 Subject: Maintainer creation policy Message-ID: <199812071907.UAA11881@office.ripe.net> Dear all, the RIPE NCC is considering relaxing the requirements for obtaining a maintainer. This has certain consequences that we would like people to consider and then put forward comments either supporting or rejecting this proposal. We propose the following new policy: - The RIPE NCC will create maintainers for all users whose person/role object is mentioned in any object in the RIPE database except if it is only mentioned in other person or role objects. - If the person/role is not mentioned in any other object, the maintainer will not be created. This should allow all users to protect their data but prevent the database from becoming some sort of "phone book". Some consequences of this would be: - The RIPE NCC would no longer do any identity checks on the requester (compliance with the policy will be, of course, checked). - Users may wish to protect objects that already have (soft) maitainers. A clear example would be a user protecting a domain object with a soft maintainer (eg: auth: NONE) with their own maintainer (which may have PGP on it). - Users with inetnum,route,etc objects are strongly encouraged to protect their objects with a strong maintainer to prevent accidental or malicious "protection" by other users. Note: Any object can have more than one maintainer. To modify/delete an object only one maintainer authentication needs to be matched. In order to add a maintainer to an object that already has one (or more) the user will need cooperation from one of the previous maintainers. Waiting for your comments, Joao Damas RIPE DB Group RIPE NCC -------- Logged at Wed Dec 9 14:38:43 MET 1998 --------- From hank at ibm.net.il Wed Dec 9 14:38:16 1998 From: hank at ibm.net.il (Hank Nussbacher) Date: Wed, 09 Dec 1998 15:38:16 +0200 Subject: FYI: .il Rules change Message-ID: <2.2.32.19981209133816.00706c50@max.ibm.net.il> After 18 months of work, the .il ccTLD will be changing its rules as of Jan 1, 1999. To review the new rules, FAQ, ACP fee schedule, etc. see: http://www.isoc.org.il/domains Regards, Hank -------- Logged at Tue Dec 29 15:45:40 CET 1998 --------- From joao at ripe.net Tue Dec 29 15:44:58 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 29 Dec 1998 15:44:58 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of Tue, 29 Dec 1998 13:50:44 +0100. <199812291250.NAA00312@snylteveps.runit.sintef.no> References: <199812291250.NAA00312@snylteveps.runit.sintef.no> Message-ID: <199812291444.PAA03362@x41.ripe.net> Havard.Eidnes at runit.sintef.no writes: * > the RIPE NCC is considering relaxing the requirements for obtaining a * > maintainer. This has certain consequences that we would like people * > to consider and then put forward comments either supporting or * > rejecting this proposal. * > * > We propose the following new policy: * > * > - The RIPE NCC will create maintainers for all users whose person/role * > object is mentioned in any object in the RIPE database except if it is * > only mentioned in other person or role objects. * > - If the person/role is not mentioned in any other object, the * > maintainer will not be created. * > * > This should allow all users to protect their data but prevent the * > database from becoming some sort of "phone book". * * Maybe I'm getting out of touch with things, but frankly, I do not see * how this solves the "phone book" problem or any other problem for that * matter. Instead I see it creating a few new problems... * Per se, it doesn't. But it prevents users from protecting their objects if the only thing they have is a person (or role) object. And, as experience goes, anything can happen to an unprotected object. As for interpretations... This is just the criteria we will use to create (or not) a new maintainer upon a user request. The RIPE NCC will not create maintainers *automatically* nor will it modify users' objects after creating a new maintainer (eg. to include mnt-by lines). This is up to the user. This doesn't reduce the phone book problem but it doesn't increase it as it would if we gave out maintainers to everyone. May be, eventually, some day, somehow, someone will carry out a free-standing, un-referenced object cleanup. The problem with creating maintainers is that they require a security override, so normal users can't do it themselves. The RIPE NCC does it upon request. * I also do not really understand from the description above what exactly * is going to happen. Some interpretations: * * o All "person" objects referenced from other objects (except "role" * objects) will result in the creation of a new maintainer object for * that user, and the user's maintainer will be added as a mnt-by: * attribute of the objects where the person was referenced earlier. * * If the total size of the database is a problem (and I think it is), * this will not help one little bit, as this will add new objects * corresponding to a *large* percentage of the person objects in the * database. * * Furthermore, it is not necessarily true that users referenced as * admin-c, tech-c or zone-c *own* the information registered, although * there may be consensus that this is so for the Internet registry part * of the RIPE database. For the other "subparts" of the database there * may be policy implications of updating the information, a prime * example could be information from the domain registry side. * * o The RIPE NCC will add mnt-by: attributes on all person objects * referenced from other objects (except "role" objects). Which * maintainer is to be used is not exactly stellar clear. I consider * this to be an unlikely interpretation, although I must say that the * statements above are sufficiently unclear that I do not clearly * understand what is going to happen. * * I do not understand at all how this will reduce the "phone book" problem * of the RIPE database, as this will not prevent the creation of "free- * standing" objects in the RIPE database (?). I furthre presume that the * "phone book" problem is exactly this -- free-standing, un-referenced * person objects? Another alternative to the "phone book" problem could * be that a large part of the RIPE database is indeed objects resulting * from it making double duty as a domain registry information repository, * although I still seem to remember statements by the RIPE NCC to the * effect that this is not regarded as a problem. * * Why not just permit maintainer object creation by anyone satisfying the * above requirements ("reference exists"), but not create the maintainer * objects themselves or the mnt-by: attributes? * * * I cannot see that there have been any comments to this proposal, so am I * the only one who does not understand what is going to happen, and what * the rationale for it is? * Well, I have tried to explain above what this is about. If there are more questions I will happily answer them. * I do however think that the effective time between announcement and * implementation is way too short -- with IETF and Christmas and New Year * holdays in-between it comes down to 1-2 weeks only. * May be it's 1-2 weeks for a particular individual but it's nevertheless a month with a lot of working days. If people think extending the implementation period is a good thing, we can do it, but it's only worth it if there is going to be a discussion about this. Keep in mind that this is mostly a RIPE NCC internal procedure (modification of the criteria for creating/denying maintainers) and the announcement is mainly intended to wake up people that have unprotected objects before maintainer availability becomes more widespread (just in case someone misuses maintainers). Regards, Joao Damas RIPE NCC * * Regards, * * - H?vard * -------- Logged at Wed Dec 30 12:06:30 CET 1998 --------- From Havard.Eidnes at runit.sintef.no Tue Dec 29 13:50:44 1998 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Tue, 29 Dec 1998 13:50:44 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of "Mon, 07 Dec 1998 20:07:26 +0100" References: <199812071907.UAA11881@office.ripe.net> Message-ID: <199812291250.NAA00312@snylteveps.runit.sintef.no> > the RIPE NCC is considering relaxing the requirements for obtaining a > maintainer. This has certain consequences that we would like people > to consider and then put forward comments either supporting or > rejecting this proposal. > > We propose the following new policy: > > - The RIPE NCC will create maintainers for all users whose person/role > object is mentioned in any object in the RIPE database except if it is > only mentioned in other person or role objects. > - If the person/role is not mentioned in any other object, the > maintainer will not be created. > > This should allow all users to protect their data but prevent the > database from becoming some sort of "phone book". Maybe I'm getting out of touch with things, but frankly, I do not see how this solves the "phone book" problem or any other problem for that matter. Instead I see it creating a few new problems... I also do not really understand from the description above what exactly is going to happen. Some interpretations: o All "person" objects referenced from other objects (except "role" objects) will result in the creation of a new maintainer object for that user, and the user's maintainer will be added as a mnt-by: attribute of the objects where the person was referenced earlier. If the total size of the database is a problem (and I think it is), this will not help one little bit, as this will add new objects corresponding to a *large* percentage of the person objects in the database. Furthermore, it is not necessarily true that users referenced as admin-c, tech-c or zone-c *own* the information registered, although there may be consensus that this is so for the Internet registry part of the RIPE database. For the other "subparts" of the database there may be policy implications of updating the information, a prime example could be information from the domain registry side. o The RIPE NCC will add mnt-by: attributes on all person objects referenced from other objects (except "role" objects). Which maintainer is to be used is not exactly stellar clear. I consider this to be an unlikely interpretation, although I must say that the statements above are sufficiently unclear that I do not clearly understand what is going to happen. I do not understand at all how this will reduce the "phone book" problem of the RIPE database, as this will not prevent the creation of "free- standing" objects in the RIPE database (?). I furthre presume that the "phone book" problem is exactly this -- free-standing, un-referenced person objects? Another alternative to the "phone book" problem could be that a large part of the RIPE database is indeed objects resulting from it making double duty as a domain registry information repository, although I still seem to remember statements by the RIPE NCC to the effect that this is not regarded as a problem. Why not just permit maintainer object creation by anyone satisfying the above requirements ("reference exists"), but not create the maintainer objects themselves or the mnt-by: attributes? I cannot see that there have been any comments to this proposal, so am I the only one who does not understand what is going to happen, and what the rationale for it is? I do however think that the effective time between announcement and implementation is way too short -- with IETF and Christmas and New Year holdays in-between it comes down to 1-2 weeks only. Regards, - H?vard -------- Logged at Wed Dec 30 12:08:06 CET 1998 --------- From phk at critter.freebsd.dk Tue Dec 29 14:52:16 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 29 Dec 1998 14:52:16 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of "Tue, 29 Dec 1998 13:50:44 +0100." <199812291250.NAA00312@snylteveps.runit.sintef.no> Message-ID: <78704.914939536@critter.freebsd.dk> It sounds to me like it would be a better solution to make a person object maintain itself in the absense of any other maintainer, basically changing to rules such that: A person object can have either a maintainer or an authentication mechanism (password/mailfrom or pgp) That would prevent a doubling of the number of records in the database. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal -------- Logged at Wed Jan 20 18:34:47 CET 1999 ---------