Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
Just a small correction, abuse-c is supported for aut-num, inetnum and inet6num in LACNIC's whois.
Regards,
Roque.
Examples from LACNIC's blocks:
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
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:
>
> http://www.apnic.net/policy/proposals
>
>
> Randy, Ching-Heng, and Terence
>
> ________________________________________________________________________
>
> prop-079-v001: Abuse contact information (abuse-c)
> ________________________________________________________________________
>
> Author: Tobias Knecht <tk at abusix dot 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
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy