[db-wg] NWI-7 proposal for fixing "abuse-c:" problems

Hi Denis,

On Thursday, April 20, 2017, 7:34:50 PM GMT+8, denis walker via db-wg <db-wg at ripe.net> wrote:
> I think you misunderstood the point about email being (in)sufficient information. I agree almost all abuse reports come via email. My >point was, what happens if the complainant gets no response to the email complaint? If the email address is all the information they >have, then they hit a brick wall. They don't know what organisation, company, individual sits behind that email address. But again, if this >is the way we move forward then we have to put our business analyst and software engineering hats on and solve the problem by >providing better information to consumers of this data.

To be fair, no one can actually tell who should be contacted as the "abuse" can be of so many kinds, the definition of abuse itself  never even reached any firm definition I believe.

Who should be contacted, in a somewhat relevant order: 
The registration information in the Assignment itself? The registration information in any intermediate layer found between an assignment and an allocation?
The LIR that issued the Assignment?
The sponsoring LIR, in case of PI?
The AS announcing the space?
The sponsoring LIR of the AS number announcing the space?
The peering AS numbers?
The RIPE NCC? 
The other RIRs?**end of RIPE Database scope of information**For other RIRs, repeat all of the above and add NIRs for some of them just to get extra complexity for everyone... Their local LEAs?
>From either policy, Database or real life point of view, all the above are valid contacts and can be relevant in reporting abuse depending on its nature.

So other than allowing/enabling an easy way for RIPE Database users that want clear ways of getting abuse report and to get that registered and displayed on queries, I don't believe it is in the power of anyone to guess where the abuse report should go.

When a user does not understand hierarchical delegation queries the Database, they also probably have no clue of route announcements, sponsoring LIRs, RIR system and so on, the educational part will be quite big then. 
I do believe that that educational information part can be made available in a simple language so that the ones who really care, can learn and crawl through the complex hierarchy and policies and the others will just give up or contact someone they know to do it for them.

Keep in mind as well that no DB data input policy or rules will ever make the "abuser" care about any reports they might receive, this discussion is only for the people who care about receiving reports, it would help a bit for the ones reporting when getting in touch with good networks and will have no effects ion reporting to "abusers" on bad networks. 


On the proposed solution with contact-org, one of the main complaints was the need to create an org Object per abuse-email, it is not alleviating that issue.

Let's not make the life of good network harder, it should be simple to manage these contact details, have an abuse-mailbox: added to inetnum could be a simple solution, LIR portal gives you an overview of all your registered objects primary keys and the abuse email linked to them.
If you want to change that, click edit/restore default/add and change the email, the first time that you replace the default value a small pop-up informing you that an abuse-mailbox: will be added to the object to replace the default abuse-c: value, done. No need to learn a new Org object hierarchy or how to make mass updates to the RIPE Database to change the abuse email for your cloud services and keep the "old" abuse email for your ISP services.

People who would prefer to do this via email/sync/webupdate, can still do it as well, no problem, it isn't breaking any systems.
Does anyone know if PI holders have access to an LIR portal like system?

Cheers
David 
Co-chair DB-WG

      From: Sebastian Wiesinger via db-wg <db-wg at ripe.net>
 To: db-wg at ripe.net 
 Sent: Thursday, 20 April 2017, 11:47
 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
  
* denis walker via db-wg <db-wg at ripe.net> [2017-04-18 16:11]:
> Colleagues Below is a proposal for fixing the problems with
> "abuse-c:" as shown in the problem statement for
> NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items
> 
> I look forward to comments.

Hello Denis,

thank you for this. I've read it three times now to understand how it
it works and I think this underlines what I tried to say in the
original problem statement:

  The problem statement looks good to me, I only would like to comment
  that the current way seems *too* complicated / bloated for a lot of
  people. So a solution should aim to be more "lightweight" for lack of
  a better word. That might happen naturally when tackling the problem
  statement but nontheless I would like to mention it.

So... I don't think this will make it easier to understand or
implement for people who just want to add an abuse contact and
subsequently will not improve abuse contact information in the
database.

> It's clear from the problem statement that some situations cannot be
> handled with the current arrangement. Mainly because it would
> require a reference to a second ORGANISATION object from a resource
> object. This is not possible with the syntax and business rules in
> the database.

Also the RIPE NCC has stated that it does not want two ORG-IDs for an
enduser. If this goes forward I think it would be a good idea to have
at least a statement from the RIPE NCC that they would be okay with an
enduser having multiple chained organisation objects for this.

> There is also a question over the double indirection to get to the
> abuse contact information, ie resource object -> ORGANISATION object
> -> ROLE object. If it is accepted that an email on it's own is not
> sufficient information and the clear link to the organisation with
> responsibility for handling abuse is also required, then this double
> indirection is needed. With the right tools it's easy to manage this
> data. This point is not a technical or operational show stopper.
> It's more about who needs what information and how do they get it.

I think it is a show stopper. You have to understand the logic and
implement the tools. Many LIRs will shy away from that. Instead just
adding an "abuse-c:" field to an object is easily understandable.

As for email being not sufficient information, in the last 10+ years I
cannot remember a single abuse complaint that was not done via email.
The only exception might be some special cases that directly involve
law enforcement or such, and for those the main ORG object should be
enough.

To sum it up, I don't think that this approach will make it easier to
add and maintain abuse information in the database and as such will
not improve the goal of having accurate and up-to-date abuse contact
information. I would not support the proposal in this form.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20170421/d88334cc/attachment.html>