This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] RIPE DB question
- Previous message (by thread): [db-wg] RIPE DB question
- Next message (by thread): [db-wg] Database updates not visible
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Thu Aug 4 15:54:15 CEST 2005
Max Tulyev wrote: > Hi! > > >>>So if you need to keep control on objects - keep your mnt-by there. >> >>In this case customer must ask LIR to do any changes in RIPE DB. >>It is not a best choise, I think. > > > But it is only choise you have if you need to keep control, for example, to > collect yearly payments for PI/AS as it usually is in RU/UA. ... another approach could be to link a resource object to more than 1 maintainer. As the access checks are performed on a "logical OR" basis, this allows modifications to be submitted by anyone holding a credential as listed in _any_ of the mntner: objects. We are doing that with some (legacy) objects of our customers. Works pretty well. Of course it assumes a collaborative environment, and/or some sort of incentive for the customer to not remove "your" maintainer (e.g. relying on your connectivity :-). It might work in your environment, and it might not be feasible. Whenever this approach is implemented, it is useful to properly configure notifications. This at least gets you a mail message if "something goes wrong" withthe collaboration.... Wilfried.
- Previous message (by thread): [db-wg] RIPE DB question
- Next message (by thread): [db-wg] Database updates not visible
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]