Okay, ill bite...
Regarding the following:
" - Refer to the nic-handle of a person or role object that contains
contact information for the appropriate dedicated abuse handling
department"
I am the tech-c for my organisation but the email address registered against my nic-handle relates to me personally, not to any relevant abuse role account holder.
From my (rather ignorant) point of view, then, the default action (to create an abuse-c and replicate the tech-c for any existing records) may cause:
- Mail directed to an inappropriate POC.
--- Obviously organisations need to get on-the-ball and create relevant role-objects or somesuch, must admit my limited interaction with the APNIC systems in this space means i don't have a full understanding of this; can the abuse-c point to a set of contact details that don't, in the end, drop to a nic-handle (i.e. an individual) ? So a role object can include a 'group' contact detail?
- Existing, invalid details replicated into abuse-c and not helping the situation at all.
--- This begs the questions...
* What are the obligations of folks to maintain their apnic data as accurate?
* Will there be any validation of these addresses before the data is replicated to abuse-c?
* Could we present a nice piece of automation that could be sent to tech-c folks asking them to quickly supply (via web form or similar) updated/revised abuse-c data and populate it that way instead (perhaps with a 'if nothing heard, we'll use tech-c' escape clause)
* Has APNIC considered emailing existing tech-c's as regards this policy, thus directly notifying the role holders of the upcoming change (rather than relying on those who actively participate in APNIC matters) and simultaneously identifying any addresses which 'dont' work' ?
One of my pet peeves is whois data that contains invalid details. Just yesterday I found yet-another-ISP with details listed by APNIC specifically for 'abuse' purposes, where the mailbox concerned didn't actually exist. I was forced to revert to a scattergun on some 'likely guesses'.
In summary I guess my issues are:
- Validating that tech-c's are infact aware that their email addresses are being recycled for abuse-c
- Validating that these tech-c/abuse-c's are actually operable and manned.
- I agree that the tech-c is the obvious starting point but a nice-and-easy way for org's to submit standalone abuse-c without drama would likely get a lot more useful buy-in on th is otherwise excellent and much-needed idea.
Mark.
(next step: Require manned and responsive abuse-c and have option for recourse if not?)
On Fri, Jan 29, 2010 at 9:04 PM, Randy Bush
<randy@psg.com> 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@abusix.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@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy