[ncc-services-wg] Feature request

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)