CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 date: Mon, 14 Jul 2025 10:55:17 GMT content-type: text/html; charset=utf-8 cf-ray: 95f07ca5df25b277-BLR cf-cache-status: DYNAMIC last-modified: Tue, 30 Jul 2024 05:34:33 GMT vary: Accept-Encoding x-content-type-options: nosniff strict-transport-security: max-age=15552000; preload server: cloudflare content-encoding: gzip [sig-policy] prop-079: Abuse contact information (abuse-c)

[sig-policy] prop-079: Abuse contact information (abuse-c)

To: Policy SIG <sig-policy at apnic dot net>
Subject: [sig-policy] prop-079: Abuse contact information (abuse-c)
From: Randy Bush <randy at psg dot com>
Date: Fri, 29 Jan 2010 03:04:07 -0500
Delivered-to: sig-policy at mailman dot apnic dot net
List-archive: <https://mailman.apnic.net/mailing-lists/sig-policy>
List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
List-post: <mailto:sig-policy@lists.apnic.net>
List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
List-unsubscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)

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:
       https://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
     https://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)
     https://lacnic.net/en/politicas/manual4.html
[4] IRT Object FAQ
     https://www.ripe.net/db/support/security/irt/faq.html

Original Source | Taken Source