<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1492103161136_410762"><span>Hi Sebastian</span></div><div id="yui_3_16_0_ym19_1_1492103161136_410773"><span><br></span></div><div id="yui_3_16_0_ym19_1_1492103161136_410856" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855">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.)</span></div><div id="yui_3_16_0_ym19_1_1492103161136_410958" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855"><br></span></div><div id="yui_3_16_0_ym19_1_1492103161136_410883" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855">We already have "sponsoring-org:", so a "contact-org:" would be fine.</span></div><div id="yui_3_16_0_ym19_1_1492103161136_411049" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855"><br></span></div><div id="yui_3_16_0_ym19_1_1492103161136_411050" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855">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.</span></div><div id="yui_3_16_0_ym19_1_1492103161136_411051" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_410855"><br></span></div><div id="yui_3_16_0_ym19_1_1492103161136_411052" dir="ltr"><span id="yui_3_16_0_ym19_1_1492103161136_411062">"</span>Instead just adding an "abuse-c:" field to an object is easily understandable."</div><div id="yui_3_16_0_ym19_1_1492103161136_411070" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1492103161136_411450" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_411451" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1492103161136_411681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_411682" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1492103161136_411683" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_411684" dir="ltr">cheers</div><div id="yui_3_16_0_ym19_1_1492103161136_411685" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_411686" dir="ltr">denis</div><div id="yui_3_16_0_ym19_1_1492103161136_411687" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_411694" dir="ltr">co-chair DB-WG<br></div><div id="yui_3_16_0_ym19_1_1492103161136_411069" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1492103161136_410763" class="qtdSeparateBR"><br><br></div><div style="display: block;" id="yui_3_16_0_ym19_1_1492103161136_410767" class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1492103161136_410766" style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1492103161136_410765" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1492103161136_410764" dir="ltr"> <font id="yui_3_16_0_ym19_1_1492103161136_410858" face="Arial" size="2"> <hr id="yui_3_16_0_ym19_1_1492103161136_410857" size="1"> <b><span style="font-weight:bold;">From:</span></b> Sebastian Wiesinger via db-wg <db-wg@ripe.net><br> <b><span style="font-weight: bold;">To:</span></b> db-wg@ripe.net <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, 20 April 2017, 11:47<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems<br> </font> </div> <div id="yui_3_16_0_ym19_1_1492103161136_410768" class="y_msg_container"><br>* denis walker via db-wg <<a shape="rect" ymailto="mailto:db-wg@ripe.net" href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> [2017-04-18 16:11]:<br clear="none">> Colleagues Below is a proposal for fixing the problems with<br clear="none">> "abuse-c:" as shown in the problem statement for<br clear="none">> NWI-7 <a shape="rect" href="https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items" target="_blank">https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items</a><br clear="none">> <br clear="none">> I look forward to comments.<br clear="none"><br clear="none">Hello Denis,<br clear="none"><br clear="none">thank you for this. I've read it three times now to understand how it<br clear="none">it works and I think this underlines what I tried to say in the<br clear="none">original problem statement:<br clear="none"><br clear="none"> The problem statement looks good to me, I only would like to comment<br clear="none"> that the current way seems *too* complicated / bloated for a lot of<br clear="none"> people. So a solution should aim to be more "lightweight" for lack of<br clear="none"> a better word. That might happen naturally when tackling the problem<br clear="none"> statement but nontheless I would like to mention it.<br clear="none"><br clear="none">So... I don't think this will make it easier to understand or<br clear="none">implement for people who just want to add an abuse contact and<br clear="none">subsequently will not improve abuse contact information in the<br clear="none">database.<br clear="none"><br clear="none">> It's clear from the problem statement that some situations cannot be<br clear="none">> handled with the current arrangement. Mainly because it would<br clear="none">> require a reference to a second ORGANISATION object from a resource<br clear="none">> object. This is not possible with the syntax and business rules in<br clear="none">> the database.<br clear="none"><br clear="none">Also the RIPE NCC has stated that it does not want two ORG-IDs for an<br clear="none">enduser. If this goes forward I think it would be a good idea to have<br clear="none">at least a statement from the RIPE NCC that they would be okay with an<br clear="none">enduser having multiple chained organisation objects for this.<div class="yqt3317122091" id="yqtfd57085"><br clear="none"><br clear="none">> There is also a question over the double indirection to get to the<br clear="none">> abuse contact information, ie resource object -> ORGANISATION object<br clear="none">> -> ROLE object. If it is accepted that an email on it's own is not<br clear="none">> sufficient information and the clear link to the organisation with<br clear="none">> responsibility for handling abuse is also required, then this double<br clear="none">> indirection is needed. With the right tools it's easy to manage this<br clear="none">> data. This point is not a technical or operational show stopper.<br clear="none">> It's more about who needs what information and how do they get it.</div><br clear="none"><br clear="none">I think it is a show stopper. You have to understand the logic and<br clear="none">implement the tools. Many LIRs will shy away from that. Instead just<br clear="none">adding an "abuse-c:" field to an object is easily understandable.<br clear="none"><br clear="none">As for email being not sufficient information, in the last 10+ years I<br clear="none">cannot remember a single abuse complaint that was not done via email.<br clear="none">The only exception might be some special cases that directly involve<br clear="none">law enforcement or such, and for those the main ORG object should be<br clear="none">enough.<br clear="none"><br clear="none">To sum it up, I don't think that this approach will make it easier to<br clear="none">add and maintain abuse information in the database and as such will<br clear="none">not improve the goal of having accurate and up-to-date abuse contact<br clear="none">information. I would not support the proposal in this form.<br clear="none"><br clear="none">Regards<br clear="none"><br clear="none">Sebastian<br clear="none"><br clear="none">-- <br clear="none">GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)<br clear="none">'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.<br clear="none"> -- Terry Pratchett, The Fifth Elephant<br><br></div> </div> </div> </div></div></body></html>