Just a small correction, abuse-c is supported for aut-num, inetnum and inet6num in LACNIC's whois.
Roque.
lainterne:~ rgaglian$ whois -l 200.7.84.0 | grep abuse-c
abuse-c: ABL2
lainterne:~ rgaglian$ whois -l 2001:13c7:7001::/48 | grep abuse-c
abuse-c: ABL2
lainterne:~ rgaglian$ whois -l 28000 | grep abuse-c
abuse-c: ABL2
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
- 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.
- 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.
- 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]
- 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.
- 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.
- 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.
- 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.
- 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
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
