<div dir="ltr">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.<div><br></div><div>Isn't it reasonable just to change the maintainer to the another one, with the unknown password?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-15 1:16 GMT+03:00 Piotr Strzyzewski <span dir="ltr"><<a href="mailto:Piotr.Strzyzewski@polsl.pl" target="_blank">Piotr.Strzyzewski@polsl.pl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Nov 14, 2014 at 11:12:44PM +0100, Job Snijders wrote:<br>
> On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:<br>
> > > Would it be an idea to prevent objects from being updated/created when<br>
> > > they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?<br>
> ><br>
> > What about delete?<br>
><br>
> We cannot delete these objects, that would wipe out a large portion of<br>
> routing information regarding Africa. That is not acceptable. I solely<br>
> mean to reject the update/creation of an object if it contains this<br>
> line:<br>
><br>
> mnt-by: RIPE-NCC-RPSL-MNT<br>
><br>
> Because the above line is a security risk for the object, everybody<br>
> knows the password for RIPE-NCC-RPSL-MNT.<br>
<br>
</span>I have been misunderstood. What about extending the protection to covers<br>
also the inability of deletion?<br>
<div class="HOEnZb"><div class="h5"><br>
Piotr<br>
<br>
--<br>
gucio -> Piotr Strzyżewski<br>
E-mail: <a href="mailto:Piotr.Strzyzewski@polsl.pl">Piotr.Strzyzewski@polsl.pl</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:12.7272720336914px">Alex Semenyaka</span><br></div></div></div>
</div>