[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 at 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 at addrex.net <mailto:william.sylvester at addrex.net>