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/[email protected]/
[db-wg] Idea: magic mntner for all LIR contacts
- Previous message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
- Next message (by thread): [db-wg] Certain sponsored? ASNs without sponsoring-org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Mon Jan 7 12:19:03 CET 2019
* denis walker via db-wg > Just to clarify a point here. Are you suggesting that for all LIRs, all listed LIR (non-billing) administrators should be able to manage all the LIR's database objects that will all be maintained by this one 'magic' MNTNER object as "mnt-by:", "mnt-lower:", "mnt-routes"? No, only that there should exist a method/functionality by which what you are describing above could be accomplised. Its use should not be made mandatory. That is, assuming this functionality is implemented as Cynthia envisioned, i.e., «auth: SSO-LIR cc.regid», then would be entirely optional to add that attribute to the maintainer object(s) used by the LIR. IFF it is added, however, then all the (non-billing) accounts associated with the «cc.regid» LIR should be authorised to maintain any objects where the maintainer object in question is included in the appropriate «mnt{,-by,-lower,-routes}:» attribute. This would be analogous to adding «auth: SSO bob at regid.cc» and «auth: SSO alice at regid.cc» to the maintainer object(s), assuming those RIPE NCC Access accounts are the only two on «cc.regid»'s user list. Another way it could be implemented is that all LIRs will automatically get such a «magic» NCC-managed maintainer object/handle which authorises all the the LIR's user accounts. The LIR could then use this magic maintainer handle in addition to, or in lieu of, regular self-managed maintainer objects/handles in the «mnt{,-by,-lower,-routes}:» attributes of its database objects. Or the LIR could opt to not use this magic maintainer object/handle for anything at all, of course. Does that clarify? Tore
- Previous message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
- Next message (by thread): [db-wg] Certain sponsored? ASNs without sponsoring-org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]