Re: [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@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@ripe.net> To: db-wg@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@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
Hi David The list you wrote below proves my point. You have used your knowledge of the hierarchy and relationships to make that. Many consumers of this data don't have that knowledge. I wasn't suggesting we document everyone on earth that could be responsible for abuse handling. The point I am trying to make is that an email address is anonymous. 'Someone/some organisation' made that email address available to report abuse to. Do abuse complainers need to know who that someone is? And it was a question that I was hoping people would answer for me. Regardless of what option we take to solve the problem statement for "abuse-c:", it may still be important to know what information people need to know or should have. That may impact on how we provide this information to consumers. If the consensus is to add an abuse contact to resource objects we should not add "abuse-mailbox:" to resource objects. It should be "abuse-c:". cheers denis co-chair DB-WG From: David Hilario <fransossen@yahoo.com> To: denis walker <ripedenis@yahoo.co.uk>; Sebastian Wiesinger <sebastian@karotte.org>; "db-wg@ripe.net" <db-wg@ripe.net> Sent: Friday, 21 April 2017, 6:12 Subject: Re: [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@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@ripe.net> To: db-wg@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@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
participants (2)
-
David Hilario -
denis walker