I would say it depends on the [future] AfriNIC procedure. I mean if the objects will be transferred not all at once but gradually there may be a situation when some objects still have to be kept in RIPE DB, and other (transferred ones) should live in AFRINIC DB. Obviously transferred objects are subject to future change, so they will have to be synchronized or removed from RIPE DB. In this scenario the object immunity can cause needless trouble.

Isn't it reasonable just to change the maintainer to the another one, with the unknown password?

2014-11-15 1:16 GMT+03:00 Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl>:
On Fri, Nov 14, 2014 at 11:12:44PM +0100, Job Snijders wrote:
> On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:
> > > Would it be an idea to prevent objects from being updated/created when
> > > they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
> >
> > What about delete?
>
> We cannot delete these objects, that would wipe out a large portion of
> routing information regarding Africa. That is not acceptable. I solely
> mean to reject the update/creation of an object if it contains this
> line:
>
>     mnt-by: RIPE-NCC-RPSL-MNT
>
> Because the above line is a security risk for the object, everybody
> knows the password for RIPE-NCC-RPSL-MNT.

I have been misunderstood. What about extending the protection to covers
also the inability of deletion?

Piotr

--
gucio -> Piotr Strzyżewski
E-mail: Piotr.Strzyzewski@polsl.pl




--
Alex Semenyaka