[db-wg] Control over associating objects for number blocks

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