Hi Job Thanks for moving this on. I think your wording below is a little bit off track as it is not about updates vs creation, but about direct references. But the DB guys at the NCC know what we mean and know how to fix it. So I think we can leave it to them now to put forward the plan & timeline. But I would ask them to take note of the comments I made in my recent Labs article about the cleanup....this may not be trivial. cheers denis On 18/05/2015 14:53, Job Snijders wrote:
Hi Group,
While it is still fresh in your minds can we get consensus on this point? This object is for hierarchical auth and should never be directly referenced in any database object by users.
To prevent this situation getting any worse is, I believe, a one line fix in the software. Adding this MNTNER name to a list of MNTNERs kept in the software that users cannot directly reference will: -prevent any new direct reference being made in user's objects -force users to replace it with their own MNTNER if they want to update an object that has a reference to this MNTNER -have no impact on the intended use for hierarchical authorisaton
I can't imagine anyone not agreeing with this, so if we get a few +1s the NCC can implement this in the next software release. When I raised the issue during the last DB-WG session at RIPE70 nobody objected to fixing this situation, one remark was made about whether
On Thu, May 14, 2015 at 07:27:42PM +0200, denis wrote: this would change any of the existing functionality to create route-objects which refer to foreign objects (answer: no), and now again the group has shown interest in pluggin this hole.
I'd like to ask RIPE NCC to provide the group with an implementation plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from being used to authenticate updates to an object after the object has been created. We also ask that the RIPE NCC look into cleaning up existing references to RIPE-NCC-RPSL-MNT and tell us their plan.
Kind regards,
Job