[db-wg] RIPE abuse finder

The overall goal is to have a correct registry and to provide registry users with the information they seek. We *want* users to come to our registry to seek this information and not rely on all sorts of tools that make even worse guesses.

We have agreed on a policy to provide mandatory abuse contact information in the long run. In the meantime we should provide the best information we can. Now if someone can *maintain* this information it serves a purpose to notify *this maintainer* of abuse in the absence of better data in the registry. Of course the intended result is that they  *maintain* the registry data *add* abuse contact information.

There is a tremendous effort coming up to implement abuse-c. It will not happen magically. It will involve a lot of maintainers and local IRs, especially in the PI cases. 

Daniel

On 06.03.2013, at 12:38 , Gert Doering <gert at space.net> wrote:

> Hi,
> 
> On Wed, Mar 06, 2013 at 12:06:33PM +0100, Denis Walker wrote:
>> There is still a link to NETASSIST-MNT:
>> 
>> inetnum:        31.133.32.0 - 31.133.63.255
>> org:            ORG-FTVM1-RIPE
>> 
>> organisation:   ORG-FTVM1-RIPE
>> admin-c:        TV1866-RIPE
>> 
>> person:         Trubnikov Valeriy
>> nic-hdl:        TV1866-RIPE
>> mnt-by:         NETASSIST-MNT
>> 
>> This nicely highlights the main problem with the legacy abuse contact 
>> management. It relies on this spaghetti of relationships between many 
>> objects in the database.
> 
> And the over-eagerness of the current abuse finder implementation - I've
> been there as well, and the usefulness of walking the inetnum -> person ->
> mnt-by -> ... chain can be seriously doubted.
> 
> I've said before that I would really prefer if you didn't do that, because
> that way, LIRs that happen to have added a person: object at some point
> in the past now happen to get abuse complaints for networks where they
> really cannot do anything, except "remove the mnt-by:" - and I really 
> doubt there are cases where this is more useful than just returning
> "uh, we did not find anything".  
> 
> Except it looks "better", of course, to return something for a higher
> percentage of queries.  Sufficiently pointy-haired metrics assumed.
> 
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
> 
>