Hi Sebastian Thanks for the comments. This proposal is just an idea that would preserve some of the benefits of the "abuse-c:" design, but I am not going to push hard for it. However, let me at least clear up some of the points you made. (Sorry for it all being top posted but yahoo doesn't allow for inline comments.) We already have "sponsoring-org:", so a "contact-org:" would be fine. Indirection and inheritance can sometimes involve complexity at the raw data level, but all of that complexity can be hidden behind simple to use tools. So I don't think that in itself is a show stopper. "Instead just adding an "abuse-c:" field to an object is easily understandable."I agree this is easily understandable. But it breaks one of the principles of the "abuse-c:" design...the "abuse-c:" attribute only exists in one place, the ORGANISATION object. Now it will be in four object types...ORGANISATION, INETNUM, INET6NUM, AUT-NUM. Before we implemented "abuse-c:" the "abuse-mailbox:" attribute was allowed in five object types...PERSON, ROLE, MNTNER, ORGANISATION, IRT. This created the mess that lead to the design of "abuse-c:" But if this is the way we go forward then we can avoid previous pitfalls with good management tools. 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. Bottom line....it is the intention of the DB-WG co chairs to resolve the issues stated in the problem statement on this round of talks. We will accept the consensus view of the community in these talks. If there is a clear consensus to add "abuse-c:" to resource objects, that is what we will ask the RIPE NCC to implement. I just want to be sure people understand the issues, both operational and technical, before making their decision. Once the decision is made, if there are other issues that may come up as a consequence, then we will solve those issues....but we must move this problem towards a resolution this time. cheers denis 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