[db-wg] Idea: magic mntner for all LIR contacts

* denis walker via db-wg

> A MNTNER object that is created by the RIPE NCC and perhaps jointly maintained by the RIPE NCC and the LIR, that is created when a new LIR is established and includes the SSO auth of all listed (non-billing) LIR contacts.
> 
> Each time a (non-billing) contact is added or removed from the LIR account the appropriate SSO auth is automatically added or removed from this MNTNER object.
> 
> Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced.
> 
> The LIR can choose if, when, where and how to use this MNTNER object.

That would solve my problem, although I do think that it is simpler and
more intuitive if this object is 100% managed by the NCC and therefore
is not allowed to go out of sync with the user list in the LIR portal.

That way you don't have to consider corner cases such as:

1) foo at bar was added to LIR account and therefore automatically to
   magic maintainer object too
2) foo at bar was manually removed from magic maintainer object
3) foo at bar was removed from LIR account user list (or changed to
   billing-only)
4) foo at bar was added back to LIR account user list (or changed back to
   regular/admin)

...should foo at bar now be re-added to the magic maintainer or not?

> A new auth option
> auth: SSO-LIR no.foobar
> 
> where SSO-LIR is automatically expanded to include all the (selected) listed LIR (non-billing) contacts for no.foobar. There could be an option in the LIR portal to mark/flag which of the LIR contacts are to be included in the expanded list.
> 
> The LIR can choose if, when, where and how to use this auth option.

That would indeed solve my problem too. I would personally have no need
for the mark/flag, though. In my case, any colleague with «Regular»
access level or above in the portal (defined as «The Operator will have
full access to RIPE NCC services») should be authorised to maintain our
database objects.

Tore