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