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,

On Thu, May 14, 2015 at 07:27:42PM +0200, denis wrote:

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
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