<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear colleagues,<div class=""><br class=""><div class=""><blockquote type="cite" class="">On 05 May 2015, at 15:59, denis walker <<a href="mailto:ripedenis@yahoo.co.uk" class="">ripedenis@yahoo.co.uk</a>> wrote:</blockquote><div class=""><blockquote type="cite" class=""><br class="">When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was:<br class="">-allowing 6 months to deploy to all members allocations<br class="">-then 12 months to deploy to all independent resources<br class="">-then do a cleanup<br class=""></blockquote><br class=""></div><div class="">I believe you are referring to this:</div><div class=""><a href="https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06" class="">https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06</a></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Can the RIPE NCC confirm that all resources now have an "abuse-c:"?</blockquote></div><div class=""><br class=""></div><div class="">No, there are still organisations without abuse-c associated with resources.</div><div class=""><br class=""></div><div class="">1 = Some LIRs are still missing abuse-c</div><div class=""><br class=""></div><div class="">Once the abuse-c has been set up for an organisation it cannot be removed, although it can be modified. However, "abuse-c:" still needs to be set for some LIRs created after phase-1 was completed. This is due to the fact that until recently new LIRs needed to create their own maintainer, abuse-c role object manually after membership activation. So new cases of LIRs that do not have an abuse-c set up were added every day.</div><div class=""><br class=""></div><div class="">We updated the member activation process recently and now a maintainer and abuse-c role are created as part of the activation process.</div><div class=""><br class=""></div><div class="">So, going forward we can now contact the remaining LIRs to set the abuse-c, and be sure that no new cases are created. We have not done this yet, because we were focusing on implementing the phase 1 and 2 of deprecating changed first.</div><div class=""><br class=""></div><div class="">2 = Not all organisations have an abuse-c</div><div class=""><br class=""></div><div class="">The RIPE NCC only has a policy mandate to enforce abuse-c for organisations associated with resources allocated or assigned through the RIPE NCC. I.e. organisations holding legacy resources or assignments made by LIRs are not covered.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.<br class=""></blockquote></div><div class=""><br class=""></div><div class="">A schema change like this would need to be discussed in the database working group, and can only be done in case "abuse-c:" can be made mandatory for all organisations - and this would also have to be discussed there.</div><div class=""><br class=""></div><div class="">From a technical point of view this change is not necessarily difficult to implement, provided that missing abuse-c roles could be created using either the existing abuse-mailbox or email attribute on organisations - presumably the addresses people would turn to today in the absence of an explicit abuse-c. So, in a way this change should not have a big semantic impact. Consistency would help to reduce complexity in documentation and business rules. It would also make it easier when assigning resources to new non-LIR organisations - now we need to check whether abuse-c has been set, because it's not mandatory and we often find that this makes dealing with requests longer.</div><div class=""><br class=""></div><div class="">But that said, the above is only a partial picture of this, and this should in our view be discussed in the database working group. We can implement after consensus is called.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Kind regards,</div><div class=""><br class=""></div><div class="">Tim Bruijnzeels</div><div class=""><br class=""></div><div class="">Assistant Manager Software Engineering</div><div class="">RIPE NCC</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></body></html>