j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
Randy and co-chairs.,
Just a small correction, abuse-c is supported for aut-num, inetnum and inet6num in LACNIC's whois.
Examples from LACNIC's blocks:
lainterne:~ rgaglian$ whois -l 220.127.116.11 | 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
On Jan 29, 2010, at 9:04 AM, Randy Bush wrote:
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:
Randy, Ching-Heng, and Terence
prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________
Author: Tobias Knecht firstname.lastname@example.org
Date: 29 January 2010
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. 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
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.
An abuse-POC exists for Organizational ID identifiers.
An abuse-c exists for Autonomous System objects.
An IRT (Incident Response Team) object can be linked to inetnum and inet6num objects.
- 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
- 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.
- 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.
 Reporting abuse and spam http://www.apnic.net/reporting-abuse
 Introduction to ARIN's Database https://www.arin.net/knowledge/database.html#abusepoc
 LACNIC Policy Manual (v1.3 - 07/11/2009) http://lacnic.net/en/politicas/manual4.html
 IRT Object FAQ http://www.ripe.net/db/support/security/irt/faq.html
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list email@example.com http://mailman.apnic.net/mailman/listinfo/sig-policy