and also keep in mind what the goal of this is. Anyone can create a new PERSON/ROLE object with the same content as one of yours. In other words make an exact copy. They can then add your MNTNER and then remove theirs after making references to it. Adding an additional MNTNER doesn't require authorisation from that MNTNER. So they can still set up their data to look as if it is managed by you. cheersdenis co-chair DB-WG On Friday, 31 May 2019, 15:11:48 CEST, Cynthia Revström via db-wg <db-wg@ripe.net> wrote: it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref... - Cynthia On Fri, May 31, 2019, 15:05 Sebastian Wiesinger via db-wg <db-wg@ripe.net> wrote: * Edward Shryane via db-wg <db-wg@ripe.net> [2019-05-27 11:43]:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Sounds good, on the premise that this is done to the generic object type and not dependent on the usage of them. Meaning that if I put mnt-ref on a person/role you cannot reference it *anywhere* unless your maintainer is listed in mnt-ref. Same for maintainers. Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant