<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_1_1430452486483_64891">Hi Billy</div><div id="yui_3_16_0_1_1430452486483_64892"><br></div><div dir="ltr" id="yui_3_16_0_1_1430452486483_64885">The reclaim functionality does cover the related routing and reverse delegation objects. That is what it was introduced for. The point you are missing is that it ONLY applies to resource objects<span style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40487"> where the RIPE
NCC has a contractual relationship with the resource holder (or their
sponsoring organisation) for that resource. If you want this functionality for legacy address space I suspect you need to consider the address policy issues before looking at database technical issues.</span></div><div id="yui_3_16_0_1_1430452486483_65449" dir="ltr"><br><span style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40487"></span></div><div style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40570"><span style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40487">cheers</span></div><div style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40571"><span style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40487">denis</span></div><div style="" class="" dir="ltr" id="yiv7653649815yui_3_16_0_1_1430452486483_40576"><div id="yui_3_16_0_1_1430452486483_65458" dir="ltr"><span style="" class="" id="yiv7653649815yui_3_16_0_1_1430452486483_40487">independent netizen</span></div></div><div id="yui_3_16_0_1_1430452486483_64829"><span></span></div><br> <div id="yui_3_16_0_1_1430452486483_64832" style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_1_1430452486483_64831" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_1_1430452486483_64830" dir="ltr"> <hr size="1"> <font id="yui_3_16_0_1_1430452486483_64833" face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> William Sylvester <william.sylvester@addrex.net><br> <b><span style="font-weight: bold;">To:</span></b> denis walker <ripedenis@yahoo.co.uk> <br><b><span style="font-weight: bold;">Cc:</span></b> "db-wg@ripe.net" <db-wg@ripe.net>; Shane Kerr <shane@time-travellers.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Friday, 1 May 2015, 14:28<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [db-wg] Proposal regarding Orphaned Objects<br> </font> </div> <div id="yui_3_16_0_1_1430452486483_64834" class="y_msg_container"><br><div id="yiv9536460784"><div id="yui_3_16_0_1_1430452486483_65210">Denis, <div id="yui_3_16_0_1_1430452486483_65216" class="yiv9536460784"><br class="yiv9536460784" clear="none"></div><div id="yui_3_16_0_1_1430452486483_65214" class="yiv9536460784">Just to be clear, this proposal is specifically for objects related to an inetnum like routing and in-addr where the maintainer is not the same as the maintainer of the inetnum. This problem is especially problematic for legacy resources. How would you better describe the situation where an object has a maintainer who is not accurately maintaining their objects? What process should a inetnum holder be subjected to for full control over their resource? In the use case of wanting to move from one service provider to another, should the inetnum holder/maintainer be able to manage and maintain their own resources? Including for example their routing objects? </div><div id="yui_3_16_0_1_1430452486483_65215" class="yiv9536460784"><br class="yiv9536460784" clear="none"></div><div id="yui_3_16_0_1_1430452486483_65211" class="yiv9536460784">One could also classify these as stale records versus orphaned. Regardless of the terminology the outcome is the same. These objects are not accurate and impede an inetnum holder from using their space. The intent of the proposal is to both increase database accuracy and enable inetnum holders to be better able to maintain all the aspects of their inetnum number block and related objects. I agree that contact objects containing personal or contact data should not be modifiable. </div><div id="yui_3_16_0_1_1430452486483_65213" class="yiv9536460784"><br class="yiv9536460784" clear="none"></div><div id="yui_3_16_0_1_1430452486483_65212" class="yiv9536460784">Thanks,</div><div class="yiv9536460784">Billy</div><div class="yiv9536460784"><br class="yiv9536460784" clear="none"></div><div class="qtdSeparateBR"><br><br></div><div class="yiv9536460784yqt1871487314" id="yiv9536460784yqt10616"><div class="yiv9536460784"><br class="yiv9536460784" clear="none"><div><blockquote class="yiv9536460784" type="cite"><div class="yiv9536460784">On May 1, 2015, at 6:56 AM, denis walker <<a rel="nofollow" shape="rect" class="yiv9536460784" ymailto="mailto:ripedenis@yahoo.co.uk" target="_blank" href="mailto:ripedenis@yahoo.co.uk">ripedenis@yahoo.co.uk</a>> wrote:</div><br class="yiv9536460784Apple-interchange-newline" clear="none"><div class="yiv9536460784">
</div></blockquote></div></div></div></div><div class="yiv9536460784yqt1871487314" id="yiv9536460784yqt80566"><div><div class="yiv9536460784"><div class="yiv9536460784" style="background-color:rgb(255, 255, 255);font-family:'Helvetica Neue-Light', 'Helvetica Neue Light', 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif;font-size:16px;"><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38734"><span class="yiv9536460784">HI</span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40486"><br class="yiv9536460784" clear="none"><span class="yiv9536460784"></span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40488"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487">Shane is correct. This functionality already exists and allows resource holders of resources allocated or assigned by the RIPE NCC to delete any operational object within their address space. Note that this functionality does not apply to any objects containing personal or contact details. Also it only applies to resource objects where the RIPE NCC has a contractual relationship with the resource holder (or their sponsoring organisation) for that resource.<br class="yiv9536460784" clear="none"></span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40569"><br class="yiv9536460784" clear="none"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487"></span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40502"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487">Just to add a caveat regarding orphaned objects, just because an object has not been updated in a very long time does not make it orphaned, even if the original maintainers are unresponsive.</span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40540"><br class="yiv9536460784" clear="none"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487"></span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40570"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487">cheers</span></div><div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40571"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487">denis</span></div><div class="yiv9536460784" dir="ltr" id="yiv9536460784yui_3_16_0_1_1430452486483_40576"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40487">independent netizen</span></div><br class="yiv9536460784" clear="none"> <div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38737" style="font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"> <div class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38736" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"> <div class="yiv9536460784y_msg_container" id="yiv9536460784yui_3_16_0_1_1430452486483_38739"> <hr class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_40697" size="1"><font class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38738" face="Arial" size="2"><b class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38752"><span class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38751" style="font-weight:bold;"></span></b></font><br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">Date: Fri, 1 May 2015 09:02:23 +0000<br class="yiv9536460784" clear="none">From: Shane Kerr <<a rel="nofollow" shape="rect" class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38810" ymailto="mailto:shane@time-travellers.org" target="_blank" href="mailto:shane@time-travellers.org">shane@time-travellers.org</a>><br class="yiv9536460784" clear="none">To: William Sylvester <<a rel="nofollow" shape="rect" class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38833" ymailto="mailto:william.sylvester@addrex.net" target="_blank" href="mailto:william.sylvester@addrex.net">william.sylvester@addrex.net</a>><br class="yiv9536460784" clear="none">Cc: <a rel="nofollow" shape="rect" class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38804" ymailto="mailto:db-wg@ripe.net" target="_blank" href="mailto:db-wg@ripe.net">db-wg@ripe.net</a><br class="yiv9536460784" clear="none">Subject: Re: [db-wg] Proposal regarding Orphaned Objects<br class="yiv9536460784" clear="none">Message-ID: <<a rel="nofollow" shape="rect" class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38805" ymailto="mailto:20150501090223.0427845f@vulcan.home.time-travellers.org" target="_blank" href="mailto:20150501090223.0427845f@vulcan.home.time-travellers.org">20150501090223.0427845f@vulcan.home.time-travellers.org</a>><br class="yiv9536460784" clear="none">Content-Type: text/plain; charset=US-ASCII<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">William,<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">On Tue, 28 Apr 2015 14:32:33 -0400<br class="yiv9536460784" clear="none">William Sylvester <<a rel="nofollow" shape="rect" class="yiv9536460784" id="yiv9536460784yui_3_16_0_1_1430452486483_38760" ymailto="mailto:william.sylvester@addrex.net" target="_blank" href="mailto:william.sylvester@addrex.net">william.sylvester@addrex.net</a>> wrote:<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">> Currently, when a number block holder wishes to update their number<br class="yiv9536460784" clear="none">> block they are unable to do so directly. They must contact the<br class="yiv9536460784" clear="none">> maintainer of the old object. Many of the older maintainers do not<br class="yiv9536460784" clear="none">> have current contact or have been acquired by another company and<br class="yiv9536460784" clear="none">> left in an unknown orphaned status. These maintainers can be<br class="yiv9536460784" clear="none">> difficult or impossible to contact. RIPE NCC then must be engaged to<br class="yiv9536460784" clear="none">> make the change to an object the number block holder should have had<br class="yiv9536460784" clear="none">> online access to manage directly in the first place.<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">As I understand it, the database allows the maintainer of<br class="yiv9536460784" clear="none">less-specific ("parent") inetnum or inet6num objects to delete<br class="yiv9536460784" clear="none">more-specific ("child") objects.<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">So, the recipient of either an allocation or assignment from the RIPE<br class="yiv9536460784" clear="none">NCC already has the power to clean up their space.<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">I believe this sort of delete functionality also applies to route and<br class="yiv9536460784" clear="none">related domain (meaning reverse DNS) objects. <br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none"><a rel="nofollow" shape="rect" class="yiv9536460784" target="_blank" href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.79/10-authorisation/10-13-reclaim-functionality-1/10-13-2-authorisation-to-reclaim">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.79/10-authorisation/10-13-reclaim-functionality-1/10-13-2-authorisation-to-reclaim</a><br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">As I understand it, your proposal has already been implemented, with<br class="yiv9536460784" clear="none">the difference that maintainers can only delete, not modify objects<br class="yiv9536460784" clear="none">that they do not directly maintain but are in their space.<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">Cheers,<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">--<br class="yiv9536460784" clear="none">Shane<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none">End of db-wg Digest, Vol 45, Issue 1<br class="yiv9536460784" clear="none">************************************<br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none"><br class="yiv9536460784" clear="none"></div> </div> </div> </div></div><br class="yiv9536460784" clear="none"></div></div></div><br><br></div> </div> </div> </div></body></html>