Hi Billy 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 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. cheersdenisindependent netizen From: William Sylvester <william.sylvester@addrex.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: "db-wg@ripe.net" <db-wg@ripe.net>; Shane Kerr <shane@time-travellers.org> Sent: Friday, 1 May 2015, 14:28 Subject: Re: [db-wg] Proposal regarding Orphaned Objects Denis,  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?  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.  Thanks,Billy On May 1, 2015, at 6:56 AM, denis walker <ripedenis@yahoo.co.uk> wrote: HI 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. 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. cheersdenisindependent netizen Date: Fri, 1 May 2015 09:02:23 +0000 From: Shane Kerr <shane@time-travellers.org> To: William Sylvester <william.sylvester@addrex.net> Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal regarding Orphaned Objects Message-ID: <20150501090223.0427845f@vulcan.home.time-travellers.org> Content-Type: text/plain; charset=US-ASCII William, On Tue, 28 Apr 2015 14:32:33 -0400 William Sylvester <william.sylvester@addrex.net> wrote:

Currently, when a number block holder wishes to update their number block they are unable to do so directly. They must contact the maintainer of the old object. Many of the older maintainers do not have current contact or have been acquired by another company and left in an unknown orphaned status. These maintainers can be difficult or impossible to contact. RIPE NCC then must be engaged to make the change to an object the number block holder should have had online access to manage directly in the first place.

As I understand it, the database allows the maintainer of less-specific ("parent") inetnum or inet6num objects to delete more-specific ("child") objects. So, the recipient of either an allocation or assignment from the RIPE NCC already has the power to clean up their space. I believe this sort of delete functionality also applies to route and related domain (meaning reverse DNS) objects. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... As I understand it, your proposal has already been implemented, with the difference that maintainers can only delete, not modify objects that they do not directly maintain but are in their space. Cheers, -- Shane End of db-wg Digest, Vol 45, Issue 1 ************************************

HI Job I am not aware of any document explaining the reasons for this limitation. There is no technical reason why it could not be extended, although the way it is currently implemented would need to be modified. But think about it from a higher level. If this functionality was to be allowed to all address space documented in the RIPE Database, what would that mean? You are asking the RIPE NCC to give permissions to Party A to override perfectly valid authorisation on objects maintained by Party B. The RIPE NCC may have no contractual relationship with either party, no knowledge of any business relationship between these two parties, no knowledge of any historical deals that may have taken place in the past and has no certain knowledge of who is the authoritative holder of all or any part of this address space. I don't think you can resolve this issue right now with a technical solution at the database level. cheers denis independent netizen From: Job Snijders <job@instituut.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: William Sylvester <william.sylvester@addrex.net>; Shane Kerr <shane@time-travellers.org>; "db-wg@ripe.net" <db-wg@ripe.net> Sent: Friday, 1 May 2015, 15:47 Subject: Re: [db-wg] Proposal regarding Orphaned Objects Dear Denis, On Fri, May 01, 2015 at 12:44:46PM +0000, denis walker wrote:

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

I learned something new today! Thank you. Is someone aware of a document that describes why the reclaim functionality was not made available to any and all inetnum holders? Is there some kind of technical limitation? Kind regards, Job

All, To clear things up, it looks like while these features may exist for certain kinds of space they do not work for all kinds of space. Specifically "status: LEGACY” blocks do not have this ability. I know this has raised some concerns about how the technical limitations are a limiting factor so much as the policy implications. In the dealing heavily with the new legacy space as we try to get the legacy blocks in the hands of people who are best able to utilize them, I have found a series of limitations where there are objects with stale data. Many of these examples appear to be older data and misconfiguration. In practice this prevents these number blocks from being accurate due to the current limitations of the existing implementation. I would say only about 20% of the time can you contact a network provider and resolve the issue. In the other 80% of the time, the emails and phone numbers do not work. In some circumstances RIPE NCC has been very helpful in being able to locate details, but this a manual process that takes time and resources. Typically, if RIPE NCC is unable to locate the party then they must make the changes which can create other requirements that should not be necessary. In my use cases, the holder of the inetnum is the ultimate authority for a number block and associated routing. It’s possible that due to historical reasons there is a lot of older data that needs cleaning up. I know for example locked ‘status: LEGACY’ objects typically have high proof of holder-ship required. Once this is done, a holder is able to have their object un-locked. These associated objects are not always included in this process. Should they be? Is there a case where an inetnum holder should not be able to dis-associate in-addr or routing objects from their inetnum? Thanks, Billy

On May 1, 2015, at 9:11 AM, Gert Doering <gert@space.net> wrote:

Hi,

On Fri, May 01, 2015 at 08:28:05AM -0400, William Sylvester wrote:

...

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.

We hear you, but you do not listen. Route: objects can be deleted already today if you have maintainer rights on the corresponding inetnum: object (mnt-routes: might be needed).

You can not *change* them, but you can delete and recreate them with current information.

Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Fri, May 01, 2015 at 07:07:00PM +0000, Shane Kerr wrote:

On Fri, 1 May 2015 11:15:52 -0400 William <william.sylvester@addrex.net> wrote:

...

In my use cases, the holder of the inetnum is the ultimate authority

In any use case I can imagine the inetnum should be the ultimate authority, it comes as a suprise to me this is not the case for some types of space. The entire security model flows from there.

I sympathize with your problem, and actually tend to agree with your philosophy here.

Why should we treat legacy networks differently from non-legacy networks?

Making it difficult to clean up related objects just results in crap in the database, and may have actual operational impact (inability to peer, incorrect reverse DNS, and so on).

So I think we should accept your proposal, which then becomes, "apply reclaim functionality using all inetnum objects".

I agree with the above. It would be much appreciated if anyone offer insight in how this came to be and why we should consider it anything else then an undocumented inconsistency (or should I just say 'bug')? Kind regards, Job

Dear all, We'd like to offer some clarification here. If the legacy holder has a contractual relationship with the RIPE NCC, the RIPE-NCC-LEGACY-MNT maintainer is added to the object, which enables the reclaim functionality. The holder of the parent object can also remove more specific route domain objects. When legacy resources are covered by a contractual relationship with the RIPE NCC, the resource holder has provided documentation that supports their claim to be the legitimate holder of those resources. 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. Please let me explain why this is the case. Legacy address space does not follow the same clear hierarchy as address space that was allocated by the RIPE NCC. The blocks we issue are "allocated" to LIRs, who can then further "assign" to their customers. In these cases, the LIR retains holdership and has responsibility over the IP block. 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. I hope this clarifies. Best regards Andrea Cima RIPE NCC On 3/5/15 18:10, Niall O'Reilly wrote:

On Fri, 01 May 2015 20:34:43 +0100, Job Snijders wrote:

...

On Fri, May 01, 2015 at 07:07:00PM +0000, Shane Kerr wrote:

...

On Fri, 1 May 2015 11:15:52 -0400 William <william.sylvester@addrex.net> wrote:

...

In my use cases, the holder of the inetnum is the ultimate authority

In any use case I can imagine the inetnum should be the ultimate authority, it comes as a suprise to me this is not the case for some types of space. The entire security model flows from there.

...

I sympathize with your problem, and actually tend to agree with your philosophy here.

Why should we treat legacy networks differently from non-legacy networks?

Making it difficult to clean up related objects just results in crap in the database, and may have actual operational impact (inability to peer, incorrect reverse DNS, and so on).

So I think we should accept your proposal, which then becomes, "apply reclaim functionality using all inetnum objects".

I agree with the above.

I think I might also, but I'm not sure I've fully understood.

...

It would be much appreciated if anyone offer insight in how this came to be and why we should consider it anything else then an undocumented inconsistency (or should I just say 'bug')?

I definitely agree with this.

Niall

Hi Shane 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 denis 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 Andrea, On Monday, 2015-05-04 17:09:54 +0200, Andrea Cima <andrea@ripe.net> 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, -- Shane

All, On Tue, 05 May 2015 09:25:05 +0100 "Niall O'Reilly" <niall.oreilly@ucd.ie> wrote:

On Mon, 04 May 2015 21:03:20 +0100, denis walker wrote:

...

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.

Thanks for explaining, Denis and Andrea.

Without knowing whether the division and distribution was intended as a sub-allocation or rather as a transfer, it's not possible (for the RIPE NCC or for another external observer) to be sure whether control over the parent block as an aggregate reasonably "belongs to" the registered organization.

This is true. However, we know that some people who maintain the parent objects are unable to correct the database. This is a problem both for those maintainers and for anyone hoping for accurate information about the network. We know there is a theoretical problem where someone might have network information deleted from the RIPE database that they want to keep there. We do not now if this is an actual problem. I remind the working group that if someone *does* have their network deleted inappropriately, then the record can be re-created. Updating a RIPE Database entry does not instantly de-peer people or the like. I'm quite happy with a dispute policy that works to always restore a more-specific inetnum object in case of complaint by the former maintainer of the object, and then lets any further resolution occur using other means. Cheers, -- Shane