* 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?
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.
"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. 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.
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. 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