Control over associating objects for number blocks
Dear Database Working Group Members, At the last RIPE meeting we discussed the topic of orphaned objects, and it seems that this term was confusing to some. This is an attempt to clarify the problem and hopefully find a solution forward. This continues to be a problem where number block holders are getting “locked” out of being able to manage their routing objects and in-addr records. Today, we continue to have a problem where a block holder does not have an ability to manage the objects that operationally impact their number blocks. Examples include a routing or reverse dns object that exist in the database but are not currently maintained by an active number block maintainer. This is typically the case where a number block holder (usually legacy) may have contracted services through a third party. Time goes by, the business relationship ends but the third party never removed their associated records (in-addrs, routing objects, etc). The number block holder now seeks to update the block (either directly or through a new service provider) and is unable to add these resource records to their number block. The database can help fix this problem through allowing the appropriate control for a number block holder to maintain their own information. In many cases the last resort is to contact RIPE NCC to make the change to an object the number block holder should have had online access to manage directly in the first place. This proposal intends to enable number block holders to have a greater ability to manage their own resources. I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems. Open items to discuss; 1) What is the best method to enable a number block holder to manage and control objects associated with their blocks in Ripe DB? 2) Should any objects be excluded from this control? 3) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester@addrex.net<mailto:william.sylvester@addrex.net>
Dear Billy, I think I understand the problem you describe and I think it is useful to try to solve it in some automatic way (i.e. without the human intervention from the RIPE NCC). I cannot, however, understand the following part:
The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block.
As an example I think of 192.168.0.0-192.168.255.255 being assigned to COMPANY and the inetnum has COMPANY-MNT as maintainer. In the database we can find the following route: route: 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered and COMPANY does not have control over AS64500-MNT. How could COMPANY modify this route in such a way that they remove the association with their assignment _without_ deleting it? The same applies to a reverse delegation, e.g.: domain: 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered Could you please clarify what you meant by the above? Did you have in mind that these could be transformed in a fake route (or domain) mobject like: route: 10.0.0.0/8 descr: orphaned 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered or domain: 10.in-addr.arpa descr: orphaned 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered respectively? Thanks and regards, Janos
Billy
William Sylvester william.sylvester@addrex.net <mailto:william.sylvester@addrex.net>
Janos, Thanks for the email, you have identified the heart of the issue. When a route exists that is not maintained by the same maintainer as the number block what should the authorization hierarchy be for that block? Especially when that record keeps a number block holder from managing the information associated with their number block. Previously we had discussed giving an upper maintainer status to the number block holder over those objects but some members of the community were worried that this might cause problems for records they wanted no control over. The intent of the language I used was specifically to avoid the issue of provided extra maintainer status for certain objects leaving that for their actual maintainer. But to have the ability to remove them from being associated with your network block. I am open to ideas on how to best accomplish this task. I know in certain cases this is already possible based on the status of your space and the tool you are using. I was mostly advocating for this feature to be available for all blocks, enabling holders to have full control over their number block. Thanks, Billy
On Oct 27, 2015, at 1:46 PM, Janos Zsako <zsako@iszt.hu> wrote:
Dear Billy,
I think I understand the problem you describe and I think it is useful to try to solve it in some automatic way (i.e. without the human intervention from the RIPE NCC).
I cannot, however, understand the following part:
The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block.
As an example I think of 192.168.0.0-192.168.255.255 being assigned to COMPANY and the inetnum has COMPANY-MNT as maintainer.
In the database we can find the following route:
route: 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
and COMPANY does not have control over AS64500-MNT.
How could COMPANY modify this route in such a way that they remove the association with their assignment _without_ deleting it?
The same applies to a reverse delegation, e.g.:
domain: 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
Could you please clarify what you meant by the above?
Did you have in mind that these could be transformed in a fake route (or domain) mobject like:
route: 10.0.0.0/8 descr: orphaned 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
or
domain: 10.in-addr.arpa descr: orphaned 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
respectively?
Thanks and regards, Janos
Billy
William Sylvester william.sylvester@addrex.net <mailto:william.sylvester@addrex.net>
HI guys You need to think about what you are doing here. If you invent a new mechanism to remove the association of a ROUTE object from some address space what does that mean? If such a mechanism was adopted, implemented and everyone knew what it means, those ROUTE objects will be ignored. So you may as well have simply deleted them. Don't try to invent a new mechanism that leaves redundant, misleading garbage in the database. This issue was discussed around the time of the last RIPE Meeting. It only relates to legacy space as RIPE address space is covered by the reclaim functionality. The question previously discussed was whether to allow the reclaim functionality to be used by top level legacy resource holders. If I remember some people were in favour and some weren't. The arguments for are to allow practical administration of legacy resources which are hindered by some historical objects. The arguments against were those occasions where some legacy resource was divided and sold/given/otherwise transferred to some other user but the RIPE NCC is not aware of that change and it is not reflected in the RIPE Database. By giving the reclaim functionality to known top level legacy resource holders they may gain control over resources they have no right to have. But that can be mitigated by the RIPE NCC being able to replace any deleted objects if someone provides the documentation to show they are the legitimate holder of the affected resource. So you need to make a decision on allowing the reclaim functionality to be used by legacy resource holders rather than inventing some parallel functionality that actually achieves the same effect with the same benefits/consequences. cheersdenis From: William Sylvester <william.sylvester@addrex.net> To: Janos Zsako <zsako@iszt.hu> Cc: "db-wg@ripe.net" <db-wg@ripe.net> Sent: Tuesday, 27 October 2015, 19:02 Subject: Re: [db-wg] Control over associating objects for number blocks Janos, Thanks for the email, you have identified the heart of the issue. When a route exists that is not maintained by the same maintainer as the number block what should the authorization hierarchy be for that block? Especially when that record keeps a number block holder from managing the information associated with their number block. Previously we had discussed giving an upper maintainer status to the number block holder over those objects but some members of the community were worried that this might cause problems for records they wanted no control over. The intent of the language I used was specifically to avoid the issue of provided extra maintainer status for certain objects leaving that for their actual maintainer. But to have the ability to remove them from being associated with your network block. I am open to ideas on how to best accomplish this task. I know in certain cases this is already possible based on the status of your space and the tool you are using. I was mostly advocating for this feature to be available for all blocks, enabling holders to have full control over their number block. Thanks, Billy
On Oct 27, 2015, at 1:46 PM, Janos Zsako <zsako@iszt.hu> wrote:
Dear Billy,
I think I understand the problem you describe and I think it is useful to try to solve it in some automatic way (i.e. without the human intervention from the RIPE NCC).
I cannot, however, understand the following part:
The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block.
As an example I think of 192.168.0.0-192.168.255.255 being assigned to COMPANY and the inetnum has COMPANY-MNT as maintainer.
In the database we can find the following route:
route: 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
and COMPANY does not have control over AS64500-MNT.
How could COMPANY modify this route in such a way that they remove the association with their assignment _without_ deleting it?
The same applies to a reverse delegation, e.g.:
domain: 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
Could you please clarify what you meant by the above?
Did you have in mind that these could be transformed in a fake route (or domain) mobject like:
route: 10.0.0.0/8 descr: orphaned 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
or
domain: 10.in-addr.arpa descr: orphaned 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
respectively?
Thanks and regards, Janos
Billy
William Sylvester william.sylvester@addrex.net <mailto:william.sylvester@addrex.net>
Dear all, Please let me try to clarify a few points related to this thread. There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources. However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects. We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties. It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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". I hope this clarifies. Andrea Cima RIPE NCC
Andrea, Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved. Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
I would have to agree with Billy here. If the goal of the NCC is to reduce the workload, the goal should be self-service, where possible. On the position that if the holder of the parent object should be the legitimate holder.. It should be that way imho.. If a part of a prefix is permanently delegated to another organisation, it should be documented in the registry and the parent prefix MUST (not should) be split up and deleted to show the actual ownership in the database. If a legacy holder of a part of a larger prefix claims they are the actual legitimate holder, they would have to provide the same paperwork and if they don't want those rights at the current legal owner of their parent prefix, this might be a good incentive for them to get the paperwork updated.. There are already proper procedures to be able to document this in place.. So why not reduce the workload more for the NCC and provide the tools for self-service for legacy holders ? Regards, Erik Bais
Op 2 nov. 2015 om 19:12 heeft William Sylvester <william.sylvester@addrex.net> het volgende geschreven:
Andrea,
Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved.
Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
Erik, You raise a very valid point, that the purpose of the database is as a directory service. This directory service ties back to the early days of the Internet. As a directory service they were intended to be used for operational and research purposes (not marketing). The operational value is directly tied to the accuracy of the data. If the RIPE Database is inhibiting any holder regardless of status from keeping their data accurate and limiting their control over their allocated resources this negatively impacts the usefulness of the database. The basic ideas that each holder should be able to appropriately reflect how their block is used and by who in conjunction with the associated resource records seems to be a reasonable idea. I support your idea of enabling the self-service tools for legacy holders utilizing the existing procedures. Thanks, Billy
On Nov 2, 2015, at 2:34 PM, Erik Bais - A2B Internet <ebais@a2b-internet.com> wrote:
I would have to agree with Billy here.
If the goal of the NCC is to reduce the workload, the goal should be self-service, where possible. On the position that if the holder of the parent object should be the legitimate holder.. It should be that way imho..
If a part of a prefix is permanently delegated to another organisation, it should be documented in the registry and the parent prefix MUST (not should) be split up and deleted to show the actual ownership in the database.
If a legacy holder of a part of a larger prefix claims they are the actual legitimate holder, they would have to provide the same paperwork and if they don't want those rights at the current legal owner of their parent prefix, this might be a good incentive for them to get the paperwork updated..
There are already proper procedures to be able to document this in place.. So why not reduce the workload more for the NCC and provide the tools for self-service for legacy holders ?
Regards, Erik Bais
Op 2 nov. 2015 om 19:12 heeft William Sylvester <william.sylvester@addrex.net> het volgende geschreven:
Andrea,
Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved.
Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
Dear all,
I support your idea of enabling the self-service tools for legacy holders utilizing the existing procedures.
While I am sympathetic to automating as much as possible in order to avoid manual work for efficiency or speed reasons, I am not happy doing it to the detriment of accountability, data security or legal clarity. My understanding now is that such an automatic tool would enable holders of legacy address space to ignore possible earlier agreements to transfer parts of the address space to other parties and in practice revoke such address space possibly even without the knowledge and obviously without the consent of those parties. This revocation could in theory be performed at present with the help of the RIPE NCC, but due to the human checks it would only occur in case the contractual relationships and the authority over the address space are properly clarified. This latter part is something that does not allow for automation. Therefore I am against this proposal. It is much safer to continue to have the authority checks performed by the NCC. Best regards, Janos
Thanks, Billy
On Nov 2, 2015, at 2:34 PM, Erik Bais - A2B Internet <ebais@a2b-internet.com> wrote:
I would have to agree with Billy here.
If the goal of the NCC is to reduce the workload, the goal should be self-service, where possible. On the position that if the holder of the parent object should be the legitimate holder.. It should be that way imho..
If a part of a prefix is permanently delegated to another organisation, it should be documented in the registry and the parent prefix MUST (not should) be split up and deleted to show the actual ownership in the database.
If a legacy holder of a part of a larger prefix claims they are the actual legitimate holder, they would have to provide the same paperwork and if they don't want those rights at the current legal owner of their parent prefix, this might be a good incentive for them to get the paperwork updated..
There are already proper procedures to be able to document this in place.. So why not reduce the workload more for the NCC and provide the tools for self-service for legacy holders ?
Regards, Erik Bais
Op 2 nov. 2015 om 19:12 heeft William Sylvester <william.sylvester@addrex.net> het volgende geschreven:
Andrea,
Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved.
Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
Janos, Thanks for the response. I think there is some confusion in regards to this proposal. The intent is to enable a number block holder to update their inaddr, routing, or dns records associated with their inetnum. It seems that the reclaim functionality may do more than is required to accomplish this. This would encourage users to properly reflect how the inetnum is being used in directory services. This encourages database accuracy and enables the data in the database to be more up-to-date. Helping the NCC reduce load and providing self-service interfaces are ancillary benefits. Thanks, Billy
On Nov 16, 2015, at 4:30 PM, Janos Zsako <zsako@iszt.hu> wrote:
Dear all,
I support your idea of enabling the self-service tools for legacy holders utilizing the existing procedures.
While I am sympathetic to automating as much as possible in order to avoid manual work for efficiency or speed reasons, I am not happy doing it to the detriment of accountability, data security or legal clarity.
My understanding now is that such an automatic tool would enable holders of legacy address space to ignore possible earlier agreements to transfer parts of the address space to other parties and in practice revoke such address space possibly even without the knowledge and obviously without the consent of those parties. This revocation could in theory be performed at present with the help of the RIPE NCC, but due to the human checks it would only occur in case the contractual relationships and the authority over the address space are properly clarified. This latter part is something that does not allow for automation.
Therefore I am against this proposal. It is much safer to continue to have the authority checks performed by the NCC.
Best regards, Janos
Thanks, Billy
On Nov 2, 2015, at 2:34 PM, Erik Bais - A2B Internet <ebais@a2b-internet.com> wrote:
I would have to agree with Billy here.
If the goal of the NCC is to reduce the workload, the goal should be self-service, where possible. On the position that if the holder of the parent object should be the legitimate holder.. It should be that way imho..
If a part of a prefix is permanently delegated to another organisation, it should be documented in the registry and the parent prefix MUST (not should) be split up and deleted to show the actual ownership in the database.
If a legacy holder of a part of a larger prefix claims they are the actual legitimate holder, they would have to provide the same paperwork and if they don't want those rights at the current legal owner of their parent prefix, this might be a good incentive for them to get the paperwork updated..
There are already proper procedures to be able to document this in place.. So why not reduce the workload more for the NCC and provide the tools for self-service for legacy holders ?
Regards, Erik Bais
Op 2 nov. 2015 om 19:12 heeft William Sylvester <william.sylvester@addrex.net> het volgende geschreven:
Andrea,
Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved.
Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
Dear William,
Thanks for the response. I think there is some confusion in regards to this proposal.
Yes, I suppose there is, see below.
The intent is to enable a number block holder to update their inaddr, routing, or dns records associated with their inetnum.
As long as there is no more specific inetnum in the database, I suppose there is no obstacle to doing so. As soon as there is a more specific inetnum registered, human check is required to assess the documentation the parties can present. However, in your mail dated 27-10-2015 14:48, you suggested the following: "I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems." The removal of "the association from their number block" or the "ability to delete the relationship between a related object and the number block" is what I find now unacceptable without human check. This is why I said I am against the proposal.
It seems that the reclaim functionality may do more than is required to accomplish this. This would encourage users to properly reflect how the inetnum is being used in directory services. This encourages database accuracy and enables the data in the database to be more up-to-date. Helping the NCC reduce load and providing self-service interfaces are ancillary benefits.
All this applies to the case where either there is no more specific inetnum (which is trivial) or the more specific inetnum is "forgotten" there. How can you tell this is the case? What happens if the more specific is legitimate, but the holder of the bigger block would like to retrieve it in an unlawful manner? In order to make sure the latter does not happen, I am against automation of the reclamation process (or deletion of the association as you call it). Best regards, Janos
Thanks, Billy
On Nov 16, 2015, at 4:30 PM, Janos Zsako <zsako@iszt.hu> wrote:
Dear all,
I support your idea of enabling the self-service tools for legacy holders utilizing the existing procedures.
While I am sympathetic to automating as much as possible in order to avoid manual work for efficiency or speed reasons, I am not happy doing it to the detriment of accountability, data security or legal clarity.
My understanding now is that such an automatic tool would enable holders of legacy address space to ignore possible earlier agreements to transfer parts of the address space to other parties and in practice revoke such address space possibly even without the knowledge and obviously without the consent of those parties. This revocation could in theory be performed at present with the help of the RIPE NCC, but due to the human checks it would only occur in case the contractual relationships and the authority over the address space are properly clarified. This latter part is something that does not allow for automation.
Therefore I am against this proposal. It is much safer to continue to have the authority checks performed by the NCC.
Best regards, Janos
Thanks, Billy
On Nov 2, 2015, at 2:34 PM, Erik Bais - A2B Internet <ebais@a2b-internet.com> wrote:
I would have to agree with Billy here.
If the goal of the NCC is to reduce the workload, the goal should be self-service, where possible. On the position that if the holder of the parent object should be the legitimate holder.. It should be that way imho..
If a part of a prefix is permanently delegated to another organisation, it should be documented in the registry and the parent prefix MUST (not should) be split up and deleted to show the actual ownership in the database.
If a legacy holder of a part of a larger prefix claims they are the actual legitimate holder, they would have to provide the same paperwork and if they don't want those rights at the current legal owner of their parent prefix, this might be a good incentive for them to get the paperwork updated..
There are already proper procedures to be able to document this in place.. So why not reduce the workload more for the NCC and provide the tools for self-service for legacy holders ?
Regards, Erik Bais
Op 2 nov. 2015 om 19:12 heeft William Sylvester <william.sylvester@addrex.net> het volgende geschreven:
Andrea,
Thank you for your comments. This feedback is interesting. To clarify, it would seem that RIPE NCC should not be intervening which the current process seems to encourage. As you stated “RIPE NCC has neither the mandate nor the resources to do this” This would indicate that providing better self-service capabilities for legacy number block holders would reduce the burden placed upon RIPE NCC while improving the ability for legacy holders to control and manage their records. This sounds like it would benefit all parties involved.
Thanks, Billy
On Oct 28, 2015, at 10:50 AM, Andrea Cima <andrea@ripe.net> wrote:
Dear all,
Please let me try to clarify a few points related to this thread.
There is currently a reclaim functionality in place for more specific INETNUM, DOMAIN and ROUTE objects, for address space that has been issued by the RIPE NCC. Here, there is a clear hierarchy in place: the LIR has an IP block with the status "allocated pa" and is the holder of the resources. The End User receives an IP block with the status "assigned pa” which must be returned when the services provided by the LIR are terminated (ripe-649). This proposal would therefore only affect legacy resources.
However, legacy IP addresses do not follow the same hierarchy as IP address space that was issued by the RIPE NCC. There is no policy mandating that address space be returned when services are terminated. Furthermore, it is not possible to know what agreements have been made over the years between the maintainers of parent and child objects.
We would like to highlight that such an implementation would mean interfering between legacy resource holders, by taking the following position: the organisation maintaining the parent object is the rightful holder of the IP block. This would ignore any potential agreements made over the years between the two parties.
It was suggested that the RIPE NCC could intervene and determine who the legitimate holder is where disputes arise. However, the RIPE NCC has neither the mandate nor the resources to do this, as outlined in our impact analysis for the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Holders": "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".
I hope this clarifies.
Andrea Cima RIPE NCC
In an effort to identify common grounds on this proposal; I would like to take some of the feedback received on and off the list to clarify the items. Establish an ability for a legacy holder to manage the associated records to their inetnum including routing and in-addr records. This feature would be available with these conditions: - only when there are no conflicting more specific subnets - the user is the maintainer of the inetnum - the inetnum matches the resource records In regards to unlawful actions taken by any party, it would make sense to have an ability to roll backwards. It would be appropriate that this might require intervention from RIPE NCC in those circumstances. I am not aware of any specific examples in the community where something like this has happened. I think if there are conflicting records in the case of a subnet attempts to establish for example a routing entry that is inconsistent with a parent block that this be blocked through sanity checking (as is done today). I do not believe that we are proposing automation of said features so much as an ability for the inetnum holder to have appropriate rights (as other existing classes of ip space do already) to properly update their associated records. Thanks, Billy
On Nov 16, 2015, at 11:19 PM, Janos Zsako <zsako@iszt.hu> wrote:
Dear William,
Thanks for the response. I think there is some confusion in regards to this proposal.
Yes, I suppose there is, see below.
The intent is to enable a number block holder to update their inaddr, routing, or dns records associated with their inetnum.
As long as there is no more specific inetnum in the database, I suppose there is no obstacle to doing so.
As soon as there is a more specific inetnum registered, human check is required to assess the documentation the parties can present. However, in your mail dated 27-10-2015 14:48, you suggested the following: "I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems."
The removal of "the association from their number block" or the "ability to delete the relationship between a related object and the number block" is what I find now unacceptable without human check. This is why I said I am against the proposal.
It seems that the reclaim functionality may do more than is required to accomplish this. This would encourage users to properly reflect how the inetnum is being used in directory services. This encourages database accuracy and enables the data in the database to be more up-to-date. Helping the NCC reduce load and providing self-service interfaces are ancillary benefits.
All this applies to the case where either there is no more specific inetnum (which is trivial) or the more specific inetnum is "forgotten" there. How can you tell this is the case? What happens if the more specific is legitimate, but the holder of the bigger block would like to retrieve it in an unlawful manner? In order to make sure the latter does not happen, I am against automation of the reclamation process (or deletion of the association as you call it).
Best regards, Janos
Denis, Thanks for your comments, the key intent would be to provide the ability for legacy holders to have control over their blocks enabling self-service of the legacy blocks. Currently, that is not the case. There are many instances where a holder must contact RIPE NCC to intervene on behalf of the number block holder. It is the intent that we just treat legacy fairly to enable legacy holders the ability to keep their own records updated. If I own a legacy number block I should have the ability to manage the records associated with my block. If a record is outdated, I should be able to use a self-service tool to updated my records. In the case where some members of the community were against enabling the reclaim functionality for legacy blocks, I would ask why they believe legacy blocks should be treated separately? From my perspective a legacy holder should have all of the same abilities. Thanks, Billy On Oct 27, 2015, at 9:09 PM, ripedenis@yahoo.co.uk<mailto:ripedenis@yahoo.co.uk> wrote: HI guys You need to think about what you are doing here. If you invent a new mechanism to remove the association of a ROUTE object from some address space what does that mean? If such a mechanism was adopted, implemented and everyone knew what it means, those ROUTE objects will be ignored. So you may as well have simply deleted them. Don't try to invent a new mechanism that leaves redundant, misleading garbage in the database. This issue was discussed around the time of the last RIPE Meeting. It only relates to legacy space as RIPE address space is covered by the reclaim functionality. The question previously discussed was whether to allow the reclaim functionality to be used by top level legacy resource holders. If I remember some people were in favour and some weren't. The arguments for are to allow practical administration of legacy resources which are hindered by some historical objects. The arguments against were those occasions where some legacy resource was divided and sold/given/otherwise transferred to some other user but the RIPE NCC is not aware of that change and it is not reflected in the RIPE Database. By giving the reclaim functionality to known top level legacy resource holders they may gain control over resources they have no right to have. But that can be mitigated by the RIPE NCC being able to replace any deleted objects if someone provides the documentation to show they are the legitimate holder of the affected resource. So you need to make a decision on allowing the reclaim functionality to be used by legacy resource holders rather than inventing some parallel functionality that actually achieves the same effect with the same benefits/consequences. cheers denis ________________________________ From: William Sylvester <william.sylvester@addrex.net<mailto:william.sylvester@addrex.net>> To: Janos Zsako <zsako@iszt.hu<mailto:zsako@iszt.hu>> Cc: "db-wg@ripe.net<mailto:db-wg@ripe.net>" <db-wg@ripe.net<mailto:db-wg@ripe.net>> Sent: Tuesday, 27 October 2015, 19:02 Subject: Re: [db-wg] Control over associating objects for number blocks Janos, Thanks for the email, you have identified the heart of the issue. When a route exists that is not maintained by the same maintainer as the number block what should the authorization hierarchy be for that block? Especially when that record keeps a number block holder from managing the information associated with their number block. Previously we had discussed giving an upper maintainer status to the number block holder over those objects but some members of the community were worried that this might cause problems for records they wanted no control over. The intent of the language I used was specifically to avoid the issue of provided extra maintainer status for certain objects leaving that for their actual maintainer. But to have the ability to remove them from being associated with your network block. I am open to ideas on how to best accomplish this task. I know in certain cases this is already possible based on the status of your space and the tool you are using. I was mostly advocating for this feature to be available for all blocks, enabling holders to have full control over their number block. Thanks, Billy
On Oct 27, 2015, at 1:46 PM, Janos Zsako <zsako@iszt.hu<mailto:zsako@iszt.hu>> wrote:
Dear Billy,
I think I understand the problem you describe and I think it is useful to try to solve it in some automatic way (i.e. without the human intervention from the RIPE NCC).
I cannot, however, understand the following part:
The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block.
As an example I think of 192.168.0.0-192.168.255.255 being assigned to COMPANY and the inetnum has COMPANY-MNT as maintainer.
In the database we can find the following route:
route: 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
and COMPANY does not have control over AS64500-MNT.
How could COMPANY modify this route in such a way that they remove the association with their assignment _without_ deleting it?
The same applies to a reverse delegation, e.g.:
domain: 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
Could you please clarify what you meant by the above?
Did you have in mind that these could be transformed in a fake route (or domain) mobject like:
route: 10.0.0.0/8 descr: orphaned 192.168.0.0/16 descr: whatever origin: AS64500 mnt-by: AS64500-MNT ... source: RIPE # Filtered
or
domain: 10.in-addr.arpa descr: orphaned 168.192.in-addr.arpa descr: whatever ... mnt-by: AS64500-MNT .. source: RIPE # Filtered
respectively?
Thanks and regards, Janos
Billy
William Sylvester william.sylvester@addrex.net<mailto:william.sylvester@addrex.net> <mailto:william.sylvester@addrex.net<mailto:william.sylvester@addrex.net>>
participants (5)
-
Andrea Cima -
Erik Bais - A2B Internet -
Janos Zsako -
ripedenis＠yahoo.co.uk -
William Sylvester