On Fri, Sep 16, 2005 at 03:30:12PM +0100, Wilfried Woeber, UniVie/ACOnet wrote:
Max Tulyev wrote:
Hi!
As I register a lot of PI/AS, there is a bit problem I often face to.
My clients wants to have control on their objects I registered for them (i.e. have their mnt-by).
But there is an agreement between us, and sometimes (due to payment problems, violating the agreement, spam, etc.) I need to suspend or even remove objects.
...which means that you want to/have to keep responsibility to maintain the data in the repository, right?
Having my mntner inside users' objects is often not acceptable because of users wants to change objects by themself (and do that quickly and transparently). Also there is administrative reason ("Why we can't change our objects, why there is alien mntner?").
I don't understand this assertion, as long as there is a contractual relationship with your LIR, there is no "alien maintainer". Please keep in mind that an LIR is NOT required to provide PI assignment services. So if those "customers" don't like your set of rules, they are free to find another LIR which offers what they want.
What you definitely _can_ do is add an _additional_ maintainer for your user. Then having any credential as listed in _any_ of the maintainers allows access. Evaluation of the auth: tags is done according to a LOGICAL OR policy.
How I can shut down objects I registered as LIR, but don't maintain?
Not at all. The maintainer mechanism was engineered to do exactly what you want to do: keep control.
Is there some special feature?
Not to my knowledge. I think I suggested that before - in case you deploy the multiple maintainer approch, you probably should enable the notification mechanism(s) [in your maintainer] to each time get an alert when your customer happens to change registration data.
And you may want to include an explicit provision in your contract that prevents your customer from removing the link to _your_ maintainer object.
Thank you.
I presume the NCC (ripe-dbm) would be in a postion to help you enforce those provisions, just in case your customers might atttempt resource hijacking.
Anything missing? If you think we need additional tools or hooks, please try to propose requirements and/or implementation ideas to the DB-WG list. Preferably before the up-coming meeting in October. (Pls. see the recently announced PDP, ripe-350)
Wilfried (DB-WG Chair)
To be honest, I don't think it is resonable for the ISP to remove the inetnum's from the RIPE db, as the customer 'owns' the resources. So the ISP can drop the routing, they can drop any route-records they have, but I don't think they can really drop the PI space inetnum objects. But please correct me if I am wrong. Regards, Andre Koopal MCI