Fw: NWI-7 proposal for fixing "abuse-c:" problems

     
----- Forwarded Message -----
 From: denis walker <dw100uk at yahoo.co.uk>
 To: Havard Eidnes <he at uninett.no> 
Cc: "db-wg at ripe.net" <db-wg at 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 at uninett.no>
 To: ripedenis at yahoo.co.uk 
Cc: db-wg at 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

   

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