________________________________________________________________________ prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________ Author: Tobias Knecht Version: 1 Date: 29 January 2010 1. Introduction ---------------- This is a proposal to introduce a mandatory abuse contact field for objects in the APNIC Whois Database to provide a more efficient way for abuse reports to reach the correct network contact. 2. Summary of current problem ------------------------------ More and more network owners are starting to establish dedicated abuse handling departments. More and more network owners are also starting to exchange abusive behavior data with each other to help source networks identify internal abuse problems faster. Currently within the APNIC region, the growing amount of abuse reports are sent to tech-c or admin-c contacts as encouraged on the APNIC website.[1] This is because APNIC Whois Database currently has no specialised contact object for abuse departments. Instead, all abuse reports are sent to the "wrong" contact first. 3. Situation in other RIRs --------------------------- AfriNIC: There are currently no specific abuse-related fields implemented in the AfriNIC Whois Database. However, if the current proposal is successful in the APNIC region, the author plans to submit a similar proposal for the AfriNIC region. ARIN: An abuse-POC exists for Organizational ID identifiers.[2] LACNIC: An abuse-c exists for Autonomous System objects.[3] RIPE: An IRT (Incident Response Team) object can be linked to inetnum and inet6num objects.[4] 4. Details of the proposal --------------------------- It is proposed that APNIC create a mandatory abuse-c. The mandatory abuse-c field should: - Refer to the nic-handle of a person or role object that contains contact information for the appropriate dedicated abuse handling department - Be mandatory in the following objects: - inetnum - inet6num - aut-num - Appear only once in an object On implementation of this proposal, all existing objects in the database would have their "abuse-c" fields automatically populated with the nic-handle(s) referred to in the tech-c field. 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Networks will be able to supply their own contact information for abuse departments. - Abuse complaints will not be sent to the "wrong" contact any more. - There will be more flexibility. Faster abuse handling will be possible leading to less abusive behavior. 5.2 Disadvantages - No disadvantages are foreseen. 6. Effect on APNIC members --------------------------- All APNIC members would need to add the mandatory abuse-c information upon this policy proposal's implementation. There are no negative effects, however, as the abuse-c fields would be populated with existing nic-handles on implementation of this proposal. 7. Effect on NIRs ------------------ It would be of benefit to the whole Internet community if NIRs were to implement a similar abuse contact scheme in their whois databases. But this would be another proposal. 8. References -------------- [1] Reporting abuse and spam http://www.apnic.net/reporting-abuse [2] Introduction to ARIN's Database https://www.arin.net/knowledge/database.html#abusepoc [3] LACNIC Policy Manual (v1.3 - 07/11/2009) http://lacnic.net/en/politicas/manual4.html [4] IRT Object FAQ http://www.ripe.net/db/support/security/irt/faq.html