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