Hi Max 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. With the introduction of "abuse-c:" this problem will be solved...in time. According to the schedule the RIPE NCC published on the Anti-Abuse Working Group the "abuse-c:" will be enforced on all allocations within 6 months and on all PI assignments after a further 6 to 12 months. If you want a 'quick fix' for the current abuse contact management, either change the "admin-c:" of the organisation above, or create a new MNTNER for the PERSON object TV1866-RIPE which has no connection with NETASSIST. If you are not responsible for this range, then as long as you break the connection between this resource and NETASSIST you will no longer be reported as the abuse contact by the Abuse Finder tool. Hope this helps. Regards Denis Walker Business Analyst RIPE NCC Database Group On 06/03/2013 11:00, Max Tulyev wrote:

Daniel,

but exactly for that case 31.133.58.219, this net is not mantained by NETASSIST-MNT, it maintaned by TRUBNIKOV-MNT, for inetnum. org, *-c and mntner (take a look in my quote or current RIPE DB whois)?

I found it _was_ maintained by NETASSIST-MNT, but a long time ago. May be there is some cache not updated?

In some cases it is not possible to ask for it at all, for a different reasons. There should be a way to solve it only from my side...

On 05.03.13 16:54, Daniel Karrenberg wrote:

...

Max,

In addition to what Dennis has said I point out the following:

The address block has no abuse-mailbox registered, otherwise we would have reported that.

None of the contacts for the address block have registered an e-mail address, otherwise we could have used that.

The admin-c person object for the address block is maintained by NETASSIST-MNT. NETASSIST-MNT has an abuse-mailbox attribute which we reported in the absence of better information. So there apparently is a connection between this address block and yourself.

If you wish to avoid abuse e-mail to your abuse-mailbox I suggest you ask the users of this address space to register e-mail addresses we can use. This can be done immediately. In the near future this will be made even easier as explained in https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...

Daniel

On 05.03.2013, at 11:52 , Max Tulyev <president@ukraine.su> wrote:

...

Hello!

Recently our company started to receive a lot of strange complaints relating to network we don't operate or route. I fount these complaints was sent to points of contact got by RIPE abuse finder.

This is the fresh sample of it:

IP: 31.133.58.219

Output of RIPE abuse finder:

https://apps.db.ripe.net/whois/use-cases/abuse-finder.json?source=ripe&primary-key=31.133.58.219

{ "abuse-resources":{ "service":"abuse-finder", "link":{ "xlink:type":"locator",

"xlink:href":"http://apps.db.ripe.net/whois/use-cases/abuse-finder.json?source=ripe&primary-key=31.133.58.219"}

, "parameters":{ "primary-key":{ "value":"31.133.58.219"} , "sources":{ "source":{ "name":"RIPE", "id":"ripe"} } } , "irt-objects":null, "abuse-mailbox-attributes":{ "attribute":{ "name":"abuse-mailbox", "value":"support@netassist.ua"} } , "objects-with-abuse-related-remarks":null} }

whois -B 31.133.58.219 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Information related to '31.133.32.0 - 31.133.63.255'

inetnum: 31.133.32.0 - 31.133.63.255 netname: DIDAN descr: FOP Trubnikov Valeriy Muhaylovich country: UA org: ORG-FTVM1-RIPE admin-c: TA3197-RIPE tech-c: TA3197-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-by: TRUBNIKOV-MNT mnt-routes: TRUBNIKOV-MNT mnt-domains: TRUBNIKOV-MNT changed: hostmaster@ripe.net 20110415 changed: hostmaster@ripe.net 20110415 source: RIPE

organisation: ORG-FTVM1-RIPE org-name: FOP Trubnikov Valeriy Muhaylovich org-type: other address: 86156, Ukraine, Makiyivka, Zeleniy, 60/182 admin-c: TV1866-RIPE tech-c: TA3197-RIPE e-mail: core@didan.org mnt-ref: TRUBNIKOV-MNT mnt-by: TRUBNIKOV-MNT changed: core@didan.org 20110414 source: RIPE

person: Trubnikov Andrey address: 86156, Ukraine, Makiyivka, Zeleniy, 60/182, phone: +380623277657 nic-hdl: TA3197-RIPE changed: core@didan.org 20110331 mnt-by: TRUBNIKOV-MNT source: RIPE

% Information related to '31.133.48.0/20AS52091'

route: 31.133.48.0/20 descr: FOP Trubnikov Valeriy Muhaylovich origin: AS52091 mnt-by: TRUBNIKOV-MNT changed: core@didan.org 20110423 source: RIPE

% Information related to 'AS52091'

aut-num: AS52091 as-name: TRUBNIKOV-AS descr: FOP Trubnikov Valeriy Muhaylovich org: ORG-FTVM1-RIPE import: from AS47694 accept ANY export: to AS47694 announce AS52091 import: from AS21189 accept ANY export: to AS21189 announce AS52091 admin-c: TA3197-RIPE tech-c: TA3197-RIPE mnt-by: RIPE-NCC-END-MNT mnt-by: TRUBNIKOV-MNT mnt-routes: TRUBNIKOV-MNT changed: hostmaster@ripe.net 20110415 source: RIPE

organisation: ORG-FTVM1-RIPE org-name: FOP Trubnikov Valeriy Muhaylovich org-type: other address: 86156, Ukraine, Makiyivka, Zeleniy, 60/182 admin-c: TV1866-RIPE tech-c: TA3197-RIPE e-mail: core@didan.org mnt-ref: TRUBNIKOV-MNT mnt-by: TRUBNIKOV-MNT changed: core@didan.org 20110414 source: RIPE

person: Trubnikov Andrey address: 86156, Ukraine, Makiyivka, Zeleniy, 60/182, phone: +380623277657 nic-hdl: TA3197-RIPE changed: core@didan.org 20110331 mnt-by: TRUBNIKOV-MNT source: RIPE

whois -B TRUBNIKOV-MNT % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Information related to 'TRUBNIKOV-MNT'

mntner: TRUBNIKOV-MNT descr: FOP Trubnikov Valeriy Muhaylovich admin-c: TA3197-RIPE upd-to: core@didan.org auth: MD5-PW # Filtered mnt-by: TRUBNIKOV-MNT referral-by: TRUBNIKOV-MNT changed: core@didan.org 20110418 source: RIPE # Filtered

person: Trubnikov Andrey address: 86156, Ukraine, Makiyivka, Zeleniy, 60/182, phone: +380623277657 nic-hdl: TA3197-RIPE changed: core@didan.org 20110331 mnt-by: TRUBNIKOV-MNT source: RIPE

Is it a bug or a feature, and why?

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

On 06.03.2013, at 13:15 , Gert Doering <gert@space.net> wrote:

Hi,

On Wed, Mar 06, 2013 at 01:05:36PM +0100, Daniel Karrenberg wrote:

...

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.

This seems to be the fundamental misunderstanding. Person: objects have a maintainer because it was added some time in the past, and not changed (since nobody stepped forward and said "I want to take over that person: object and put my maintainer on it").

This has nothing to do whatsoever with maintaining the address space that happens to reference this person object.

Following this particular chain is just causing work for unrelated people - and yes, our consequence to this approach by the RIPE NCC is to remove our mnt-by: from person: objects that cause misdirected abuse reports, leaving them unmaintained. Congrats on great incentives for LIRs to improve DB quality.

There is no misunderstanding here at all. If you remove a maintainer this just exposes the fact that indeed you do no longer consider yourself responsible for maintaining these person objects. If no-one else puts on their maintainer and assumes responsibility the object is just unmaintained. But as long as a mnt-by: exists the assumption has to be that the maintainer is indeed responsible to maintain the data and indeed also for maintaining abuse contact information. Note well that the mnt-by: attribute gives the maintainer the authority to make changes. What value a user attaches to any unmaintained information in the database is another question. Whether the community considers it valuable to keep unmaintained data in the database is another. And finally whether there should be a requirement to have at least one maintainer for all objects that comprise the RIPE Internet Number Resource Registry is a third question. But I see no harm in exposing the fact that no-one considers themselves responsible for maintaining certain objects. And this has nothing to do with pointed-hairedness at all. As a community we cannot avoid responsibility to maintain data in the registry and expect a high quality registry at the same time. We have to face this, put in the required effort and evolve the registry and its rules. Otherwise we will end up with a useless heap of data. Daniel

On 06.03.2013, at 14:46 , Gert Doering <gert@space.net> wrote:

Hi,

On Wed, Mar 06, 2013 at 02:00:01PM +0100, Daniel Karrenberg wrote:

...

There is no misunderstanding here at all. If you remove a maintainer this just exposes the fact that indeed you do no longer consider yourself responsible for maintaining these person objects. If no-one else puts on their maintainer and assumes responsibility the object is just unmaintained. But as long as a mnt-by: exists the assumption has to be that the maintainer is indeed responsible to maintain the data and indeed also for maintaining abuse contact information. Note well that the mnt-by: attribute gives the maintainer the authority to make changes.

Yes - I feel responsible to update that person: object, if need arises.

There seems to be a need for an abuse-mailbox for this person object or their resources ...... ;-) I would not be surprised that you may also very well be the person that we will have to ask for an an abuse-c soon ...

You are constructing a responsibility to handle network abuse coming from an inetnum: that happens to reference this person: object from this (which whould be logical to assume for the the mntner of an *inetnum:* object).

We do not. You know exactly where the "delete" key is. Of course it would be better if you forwarded the message to the person whose object you feel responsible to maintain. I am the first to agree that we need to communicate the "quality" of the information we provide. That is why we included a "star rating" in RIPEstat. This needs further optimisation sure ...

This is what I'm objecting to.

We as a community have to maintain an accurate registry. the first responsibility for this is with the "maintainers". Abuse contact information is a part of that because there is a need for it from users of the registry. We have policies in place to improve that significantly, but we cannot just halt everything until they are fully implemented. It would be very very bad if we as a community are perceived to be unable to maintain an accurate registry and to answer legitimate user queries. All sorts of entropy of the could arise from that, above all that of the regulatory kind.

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

On Mon, Mar 18, 2013 at 11:25:08AM +0100, Gert Doering wrote:

But I do not accept implied responsibility by ill-designed tools trawling along all possible cross-connects in the database to be able to return "something", instead of having to answer "we're sorry we could not find an abuse contact".

I agree with Gert. The tool's logic is flawed and actually detrimental to the data quality of the RIPE DB since it provides an incentive to create duplicate person entries. A "maintainer" is responsible for the database object, not for the entity (or person) referenced by it. -Peter

On 19.03.2013, at 9:08 , Peter Koch <pk@DENIC.DE> wrote:

I agree with Gert. The tool's logic is flawed and actually detrimental to the data quality of the RIPE DB since it provides an incentive to create duplicate person entries. A "maintainer" is responsible for the database object, not for the entity (or person) referenced by it.

-Peter

Gert, Peter, I understand the pain such ill addressed messages cause, believe me. I have personally been getting them since the first appearance of spam. My address was in many remarks fields in our registry. It has not gotten better when all sorts of intrusion detection systems started sending automated mails to what they thought the best contact information was for an IP address. And mind you, my mail address is on RFC1918 too. ;-( I have always tried to find the cause for such messages ending up with me and to correct the registry such that they end up in the correct person's mailbox. Often this has not been easy, because it was impossible to determine the flawed logic in tools I did not even know existed, let alone that i could know for sure how they worked. This is why I feel strongly about both having good information in the registry and about the RIPE NCC maintaining authoritative tools to find it. I know that these days it is not easy since some people intentionally obfuscate heir information in the registry. I observe that the more obfuscated the registration information is, the higher the demand for abuse contact information. The start of this thread by Max seems to be a case in point to me. I am the first to agree that the current abuse-finder logic needs improvement. I also agree that abuse-c is the right way to go. I am concerned about the time between now and Q3/2014 when current plans call for abuse-c to be fully deployed. Deployment is going to be a lot of hard work on the part of both the maintainers and the RIPE NCC. My concern is that we as a community who operate the RIPE registry will look unresponsive to justified demands for abuse contact information if we do not make an effort to provide the best abuse contacts we can find in our registry now. Telling people that ask for this information that we will be ready in Q3 next year is not going to reflect well on our ability as a community to keep our house in order. My point is that we should do three hings: - implement abuse-c (well under way) - do our very best to populate the registry with good abuse contact information - fix any flaws in the abuse-finder and the RIPEStat abuse-contat widget that is based on it In the mean time it would be best if we tried to improve the registry information for any abuse mail that winds up in our mailboxes. Daniel