Fw: NWI-7 proposal for fixing "abuse-c:" problems
----- Forwarded Message ----- From: denis walker <dw100uk@yahoo.co.uk> To: Havard Eidnes <he@uninett.no> Cc: "db-wg@ripe.net" <db-wg@ripe.net> Sent: Thursday, 20 April 2017, 0:51 Subject: Re: NWI-7 proposal for fixing "abuse-c:" problems Hi Havard Thanks for the response. Let me make a few points here. Firstly I am not trying to justify why such information is required. I asked the question (twice) 'if' this information is required and I got one reply. I am still hoping more people will comment so we can decide if this is required. I put forward this proposal on the assumption that more details are required, based on past discussions, but this may not be the case. Adding "abuse-c:" to resource objects will solve the technical problems in the problem statement. But if that is the solution that we end up adopting then the RIPE NCC MUST provide the tools necessary to manage this hierarchically structured information. After 14 years of working inside this database, analysing what people do with it, 'just' adding "abuse-c:" to resource objects will create a mess within a few years. This is why we created "abuse-c:" in the first place. As you point out the resource holder is ultimately responsible for abuse related to their resources. But many consumers of this abuse contact information don't understand the resource hierarchy or the contractual relationships between the parties. So if we only provide consumers with a single abuse email address and they get no response, they hit a brick wall. This is why I asked the question above. To solve the technical questions we need to know what information consumers need and how best to provide it. cheers denis co-chair DB-WG From: Havard Eidnes <he@uninett.no> To: ripedenis@yahoo.co.uk Cc: db-wg@ripe.net Sent: Wednesday, 19 April 2017, 23:53 Subject: Re: NWI-7 proposal for fixing "abuse-c:" problems Hmm, I'm not entirely happy with this proposal. In brief, I think it overcomplicates matters. It seems to me that this proposal may give rise to creation of "pseudo-organizations" in the RIPE database. I think this will dilute the value of the organization objects, since you can no longer in a reasonable way expect that an organization object in the RIPE database represents a real genuine real-world organization. I agree it's a good idea to provide the default value of the abuse handler via the organization object. What I don't understand is the apparent reluctance to permit per-resource simple overrides of this inheritance, something which could be done by allowing the marking of resource objects with abuse-c pointing to a role object for the abuse handler for the resource. Why insist on an indirection via an organization object for this override? So... I guess I don't understand this justification:
If it is accepted that an email on it's own is not sufficient information [...]
Pointing to an abuse role object via abuse-c provides more than just an e-mail address.
[...] and the clear link to the organisation with responsibility for handling abuse is also required, then this double indirection is needed.
Can you please expand the justification for why this information is required? Isn't it just as likely that the information provided in such a "must be registered" organization will just be a "pseudo- organization" where the the only thing which causes it to spring into existence is the insistence of the (proposed) RIPE DB data model? Ultimately the responsibility for the use of the resource rests with the organization holding the resource, so that's always a possible recourse should the overriding abuse-c prove to produce non-satisfactory results. Best regards, - Håvard
participants (1)
-
denis walker