Dear SIG members,

The proposal, 'Abuse contact information (abuse-c)', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.

We invite you to review and comment on the proposal on the mailing list before the meeting.

The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal:

- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective?

Information about this and other policy proposals is available from:

http://www.apnic.net/policy/proposals

Randy, Ching-Heng, and Terence

________________________________________________________________________

prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________

Author: Tobias Knecht tk@abusix.org

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