Hi Sebastian


On 21/04/2017 14:09, Sebastian Wiesinger wrote:
* denis walker via db-wg <db-wg@ripe.net> [2017-04-20 13:35]:
Date: Thu, 20 Apr 2017 11:34:22 +0000 (UTC)
From: denis walker <ripedenis@yahoo.co.uk>
To: Sebastian Wiesinger <sebastian@karotte.org>, "db-wg@ripe.net"
 <db-wg@ripe.net>
Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
Reply-To: denis walker <ripedenis@yahoo.co.uk>
Message-ID: <1214539347.1395203.1492688062209@mail.yahoo.com>
X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Macintosh; Intel
 Mac OS X 10.7; rv:48.0) Gecko/20100101 Firefox/48.0

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.)
Hi Denis,

sorry I'm having a really hard time reading your mails, I have to do
extensive reformatting. Could you perhaps use a mail client that
doesn't produce a wall of text?

I will try Thunderbird as a front end, but it still goes through yahoo and may still get messed up....


We already have "sponsoring-org:", so a "contact-org:" would be fine.
Why is having three fields named *some*-org better than two? That the
field is called contact-org or abuse-c or abuse-mailbox should not
matter, right?

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.
Will you build the tools so that everyone can use them? If you can
build tools you can work around almost anything but I'm thinking about
people who edit the object on the webportal to add an abuse contact or
send it to the mail interface.

No one supports the idea so I don't think it matters now.


"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.
What management tools do you mean? Every LIR would have to implement
these if we don't make it easy enough to use it by hand.

After 14 years of analysing how people use this database and play around with it's algebraic, raw data and providing technical support when things go wrong, I foresee potential issues when we apply apparent 'simple solutions'. But lets wait and see what the final consensus is and then consider possible consequences and address them.


In my mind the goal is to add the attribute at the level it is used
and that would be inet(6)num and maybe autnum. This was not done
before.

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.
If the complaint gets no response by mail then most people will not go
further anyway. What good would it do them to know which person or
company sits behind that mailadress? They didn't get a response. *If*
they want to dig deeper they can still look at the org object or
admin/tech contacts and so on.

I was asking a question, not giving an answer. I was hoping people who process abuse reports might have contributed towards an answer. But again you are assuming people who make abuse complaints understand the structure of this database. I don't know if that is true or not.


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.
At least that would be my preferred solution if noone has a simpler one.

Noted.

cheers
denis
co-chair DB-WG

Regards

Sebastian