Thanks for that point. Tobias Roque Gagliano schrieb: > Randy and co-chairs., > > 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 > > * 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
Attachment:
signature.asc
Description: OpenPGP digital signature