<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"><tt style="" class="">Hi Shane</tt> In a neat and perfect world where everyone had all documentation for all contracts, deals, agreements that have ever been made regarding address space, then I agree there is no problem giving out these permissions as everything can be put right if mistakes are made. However, we don't all live in that perfect world. There have been examples where a block of addresses was given to an organisation many years ago to be divided up and distributed to other organisations. But sometimes that parent block still exists in the RIPE Database and is registered with an organisation. If we give this organisation the reclaim permissions 'by default' they can delete anything they want. Suppose you and I each have a part of this address space. This organisation deletes my INETNUM, ROUTE and DOMAIN objects using the reclaim functionality. But I never throw anything away so I still have the agreement to show it is my address space. I prove it to the RIPE NCC, they reinstate all my data and divide up the top level block to make mine also a top level block. Everything is fine. Now this organisation deletes your objects. But you no longer have the original agreement showing it is your address space. What are you going to do? You can't put anything back in the RIPE Database yourself. This organisation may choose not to put anything back as they now have control of your address space. The RIPE NCC will do nothing as you can't prove it was ever your address space. So even though everything was fine yesterday, no one was contesting your authority over these addresses you have been using for the last 10+ years, your routing and delegation is working fine....suddenly you are in a mess that no one can get you out of. That is what Andrea meant when he said "It is often not clear if the legitimate holder of these resources is the organisation that received the resources from InterNIC for redistribution, or the subsequent organisation that received the resources." To give reclaim functionality by default to the holders of all top level legacy blocks means 'disregard all early redistribution arrangements unless proven'. This is the opposite of the current situation which is 'the status quo remains unless all parties involved come to an agreement'. So you take your pick of which position you want to take. cheers <div id="yui_3_16_0_1_1430668032630_51522" dir="ltr"> denis</div><div id="yui_3_16_0_1_1430668032630_51411"></div> <div id="yui_3_16_0_1_1430668032630_51515" 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_1430668032630_51514" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_1_1430668032630_51519" dir="ltr"> <hr size="1"> From: Shane Kerr <shane@time-travellers.org> To: Andrea Cima <andrea@ripe.net> Cc: "db-wg@ripe.net" <db-wg@ripe.net> Sent: Monday, 4 May 2015, 21:03 Subject: Re: [db-wg] Proposal regarding Orphaned Objects </div> <div id="yui_3_16_0_1_1430668032630_51513" class="y_msg_container"> Andrea, On Monday, 2015-05-04 17:09:54 +0200, Andrea Cima <<a shape="rect" ymailto="mailto:andrea@ripe.net" href="mailto:andrea@ripe.net">andrea@ripe.net</a>> wrote: > In cases where legacy resources are not covered by a contractual > relationship, the RIPE-NCC-LEGACY-MNT is not added, and so this > functionality is not available. Right. > With regards to legacy resources, we mentioned the following in our > impact analysis of the policy proposal: > > >> It is often not clear if the legitimate holder of these resources > >> is the organisation that received the resources from InterNIC for > >> redistribution, or the subsequent organisation that received the > >> resources. It is therefore not clear which of the organisations > >> involved has the right to enter into a contractual agreement. > >> > >> When the situation presents itself where there are multiple layers > >> of legacy resources distribution, it is the responsibility of the > >> parties involved to find an agreement on which party is the > >> legitimate holder of the legacy resource. Only when the parties > >> involved have agreed on a decision, the RIPE NCC will evaluate a > >> contractual relation request. > > > In cases where holdership is unclear, the RIPE NCC needs to remain > neutral and impartial for all organisations involved. Allowing the > organisation maintaining the parent inetnum object to remove > everything more specific would essentially mean taking a strong > position regarding who the legitimate holder of the address space was. > > However, in cases where a contractual agreement is in place, the > holder of the resources has already provided documentation supporting > their claim to holdership of the resources, and have confirmed that > they will follow RIPE Policies and RIPE NCC procedures. > > Of course, if the community believes that the holders of parent > objects should automatically gain authority over everything more > specific, we can implement this. So basically the answer is, "just sign a contract and you can clean up your address space". While I sympathize with the RIPE NCC's position, the end result is that this makes it more difficult to get correct information into the database. I can easily imagine a well-intentioned network administrator would be unwilling or unable to deal with the hassle of updating contracts, so just gives up. Ultimately we are talking about changes to the database. The cost for error is having to reverse these changes later. If someone has a well-maintained inetnum object and it is deleted inappropriately then they will get notified and can immediately start getting it fixed. Personally I am happy for the parent objects to gain authority over everything more specific. Cheers,<div class="qtdSeparateBR"> </div><div class="yqt3499399864" id="yqtfd41081"> -- Shane </div> </div> </div> </div> </div></body></html>