Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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
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/proposalsRandy, Ching-Heng, and Terence
prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________
Author: Tobias Knecht tk@abusix.org
Version: 1
Date: 29 January 2010
- 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.
- 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.
- 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]
- 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 objectOn 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
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.
- 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.
- 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
Hi Mark,
thank you for your time asking these questions.
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.
The status at the moment is, that APNIC suggestst the usage of admin-c or tech-c for abuse reporting. That way everybody would use your personal address to report to. As you already mentioned that is not the good way.
Therefor the idea is to add an abuse-c. And populate it with existing tech-c information. Which makes no difference to the status now. But it gives the opportunity to create an role account and populate the abuse-c with that. So in the very beginning there is no change, the change happens just if you want it.
The result is more flexibility.
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?
As I understand the proposal and as I would like to have it implemented there must be the possibility to add an role object. That is what I would suggest every netrange owner to add an abuse role account and not a personal handle.
- Existing, invalid details replicated into abuse-c and not helping the
situation at all. --- This begs the questions...
Full Ack. And this begs questions at every RIR in the world. And as I know there are huge discussions about the data accuracy at RIPE at the moment.
- 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?
That would be good.
- 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' ?
I think an email reminder that tell netrange owners every 3 month to check if everything is still accurate and klick a link to aknowledge would be a perfect thing. Sometimes I hear people say, we don't think about updating our whois information, because we just forget about it. It's not even intentional.
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.
Lot's of good ideas. And I think there is potential for another policy proposal.
Thanks,
Tobias
-- | Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt) | tk@abusix.org | http://abusix.org | Postfach 210127 | 76151 Karlsruhe | Germany | --- | Register of Companies(Handelsregister): HRB 707959 | District of Court(Amtsgericht) Mannheim/Germany | Registered Office: Karlsruhe/Germany | CEO: Tobias Knecht
2010/1/30 Tobias Knecht knut@abusix.org
Hi Mark,
thank you for your time asking these questions.
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.
The status at the moment is, that APNIC suggestst the usage of admin-c or tech-c for abuse reporting. That way everybody would use your personal address to report to. As you already mentioned that is not the good way.
Therefor the idea is to add an abuse-c. And populate it with existing tech-c information. Which makes no difference to the status now. But it gives the opportunity to create an role account and populate the abuse-c with that. So in the very beginning there is no change, the change happens just if you want it.
The result is more flexibility.
I fundamentally agree with the idea of an abuse-c (or similar) being compulsary; netblock holders should be encouraged to provide actual, legitimate details.
You have to start somewhere. As Mike Jager? Noted, folks are already automating the process and scraping out admin-c or tech-c POCs, and they may well not change behavior. However if _everyone_ had an abuse-c and could rely on it actually being valid, folks can change...
(You have to start somewhere. That's part of why I at this stage, approve of this idea.)
As I understand the proposal and as I would like to have it implemented there must be the possibility to add an role object. That is what I would suggest every netrange owner to add an abuse role account and not a personal handle.
Excellent.
- 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?
That would be good.
I'd like to see it pursued. I see invalid data in whois detail as a bigger problem than the mandatory-or-not-ness of abuse-c, to be honest.
- 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' ?
I think an email reminder that tell netrange owners every 3 month to check if everything is still accurate and klick a link to aknowledge would be a perfect thing. Sometimes I hear people say, we don't think about updating our whois information, because we just forget about it. It's not even intentional.
Annually would be sufficient. My .com domains are subject to a yearly prod by my registrar to ensure the whois data is current... there's precedent here.
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.
Lot's of good ideas. And I think there is potential for another policy proposal.
I will be watching for comment from those more learned than myself in this area. Thanks for the feedback, Tobias and others.
Mark.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have yet to see a reason to agree to this proposal in current form, if theare are no mechanisms to make sure that the data field
a) won't get populated by existing members b) won't get updated and validated on a regular basis.
If the (b) is part of the policy, then I am all for it.
This actually brings up the question why is there no effort to validate whois information, and as Mark Foster pointed out - those of us with .com domains seems to get that on a regular interval.. I don't see a reason it can't be the same for IP/ASN resources.
- -gaurab
Hi,
I have yet to see a reason to agree to this proposal in current form, if theare are no mechanisms to make sure that the data field
a) won't get populated by existing members b) won't get updated and validated on a regular basis.
If the (b) is part of the policy, then I am all for it.
This actually brings up the question why is there no effort to validate whois information, and as Mark Foster pointed out - those of us with .com domains seems to get that on a regular interval.. I don't see a reason it can't be the same for IP/ASN resources.
I think it would ake sense to start another proposal, that looks for a yearly update request or something similar. But Where is the sense of putting it to this proposal for abuse-c and leaving out the admin-c and tech-c.
If there is so much unity about this. Let's start this proposal as soon as possible.
Thanks,
Tobias
On 1/02/10 Mon, Feb 1, 00:56, Gaurab Raj Upadhaya wrote:
Hi,
I have yet to see a reason to agree to this proposal in current form, if theare are no mechanisms to make sure that the data field
a) won't get populated by existing members b) won't get updated and validated on a regular basis.
If the (b) is part of the policy, then I am all for it.
I agree with Gaurab. There's little evidence to show that people keep their admin-c and tech-c details up to date - an abuse-c will simply follow the same path unless there is a mechanism to update and validate it.
Some sites are diligent about processing email to abuse@xxxx.yyy, others for whatever reason effectively route such mail to /dev/null. Having a compulsory field won't change that.
If/when we get to the stage where an IP address resource has a signed certificate which allows it to be routed and this has an annual renewal then APNIC might have some lever which coerced resource holders into doing the right thing. Until then they don't have much leverage.
On 29/01/10 23:04, Mark Foster wrote:
- 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?
A role object looks like:
role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
As you can see, both admin-c and tech-c are required. So while someone looking to obtain abuse-c contact details could be presented with a role object, there's nothing stopping them looking up the admin-c and tech-c attributes of that role object, which may well end up being individual person objects, and using those contact details as well (or instead).
Indeed, I suspect that many people looking to obtain abuse-c contact details will likely continue to do this...
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'.
...and not necessarily because the email address in the abuse-c role object doesn't work. I have seen abuse complaints sent to any address associated (directly or indirectly) with an inetnum object, including the admin-cs and tech-cs of the role object that is in turn the admin-c and tech-c for the inetnum.
Assuming this policy is implemented, there would now be an obvious place to send abuse reports. However, there would be nothing stopping (perhaps automated?) abuse reports continuing to be sent to to admin-c/tech-c. I have nothing against the goal of this policy, but I'm not sure that the addition of an abuse-c to inetnums, inet6nums, and aut-nums will result in abuse mail no longer being sent to admin-c/tech-cs of those objects.
However, I'm more than happy to be proven wrong on that :)
-Mike
Most of the abuse emails are generated through automated scripts which parse the whois information. Although I'm in favor of this policy but as Mike said, we can't be sure that email will be delivered to abuse-c rather than admin-c or tech-c.
Still in favor.
Regards,
Aftab A. Siddiqui
Regards,
Aftab A. Siddiqui
On Sat, Jan 30, 2010 at 12:15 PM, Mike Jager mike@mikej.net.nz wrote:
On 29/01/10 23:04, Mark Foster wrote:
- 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?
A role object looks like:
role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
As you can see, both admin-c and tech-c are required. So while someone looking to obtain abuse-c contact details could be presented with a role object, there's nothing stopping them looking up the admin-c and tech-c attributes of that role object, which may well end up being individual person objects, and using those contact details as well (or instead).
Indeed, I suspect that many people looking to obtain abuse-c contact details will likely continue to do this...
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'.
...and not necessarily because the email address in the abuse-c role object doesn't work. I have seen abuse complaints sent to any address associated (directly or indirectly) with an inetnum object, including the admin-cs and tech-cs of the role object that is in turn the admin-c and tech-c for the inetnum.
Assuming this policy is implemented, there would now be an obvious place to send abuse reports. However, there would be nothing stopping (perhaps automated?) abuse reports continuing to be sent to to admin-c/tech-c. I have nothing against the goal of this policy, but I'm not sure that the addition of an abuse-c to inetnums, inet6nums, and aut-nums will result in abuse mail no longer being sent to admin-c/tech-cs of those objects.
However, I'm more than happy to be proven wrong on that :)
-Mike
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
Tobias and policy boffins.
On 29/01/2010, at 6:04 PM, Randy Bush wrote:
- Do you support or oppose this proposal?
Do not support..
- Does this proposal solve a problem you are experiencing? If so, tell the community about your situation.
I don't believe adding another mandatory contact to the objects themselves helps anyone or anything as the scatter gun approach seems to always be used in a reporting process.
looking at the role account.
$ whois -h whois.apnic.net -- "-t role" % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
There exists an abuse-mailbox field does that not satisfy the need for those "more and more" organisations that are building abuse teams??
Note to APNIC:
The templates and the attributes at http://archive.apnic.net/db/ref/attributes/attributes-role.html (presumably archived but still the only whois documentation you have linked on the main website) do not agree!
The website lists:
"trouble | Can be used to include details on where to send abuse complaints."
and while it reflects a set of data:
ie:
role: Optus Internet address: Level 3, 11 Help Street address: Chatswood, NSW 2067 country: AU phone: +61-2-9027-1127 fax-no: +61-2-9027-1035 e-mail: oie-netops@optus.com.au trouble: Send spam/abuse reports to abuse@optusnet.com.au admin-c: OI1-AP tech-c: OI1-AP nic-hdl: OI3-AP notify: oie-netops@optus.com.au mnt-by: MAINT-AU-OPTUSINTERNET changed: oie-netops@optus.com.au 20040502 changed: hm-changed@apnic.net 20041020 changed: hm-changed@apnic.net 20041020 source: APNIC
it appears out of date with the whois schema.
- Do you see any disadvantages in this proposal?
Lets say you do add a mandatory abuse object to the inet(6)num/aut-num.
Since most allocations come with the text:
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This object can only be updated by APNIC hostmasters. remarks: To update this object, please contact APNIC remarks: hostmasters and include your organisation's account remarks: name in the subject line. remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
You are actually asking APNIC to update all of those allocation inet(6)nums with the extra object. Now lets assume you do automate that, fine. Every organisation that wants it changed now needs to "contact APNIC hostmasters", or are you asking the hostmasters to solicit that information?
I'm going to guess (a cynical guess) that many organisations will not request the update to the automated addition of 'abuse-c:', leaving multiple superfluous contacts.
- Is there anything in the proposal that is not clear?
"more and more" appears vague. do you have any statistics? (section 2)
I believe your disadvantages are understated. The examples above suggest that the whois data is not consistent to the whois schema. Adding a further change bites into a whois database consistency issue, that really shouldn't exist, but does where the APNIC secretariat will probably need to expend significant resources on rectifying, provided they have resources to spare.
- What changes could be made to this proposal to make it more effective?
I can see where you are coming from, trying to make the contact process for abuse/fraud/crime easier is admirable. I just don't think this will make any positive difference.
I would suggest that serious levels of contact information is not found in whois, and if you wanted to try to 'force' the information out of member organisations via the RIR I would suggest an RIR facilitated LEA or 'trusted entity' web portal that provides a deeper look into networks (under the conditions of the membership agreement) to be of more use as less organisations would redirect those contacts to /dev/null
Cheers Terry
Hello,
- Does this proposal solve a problem you are experiencing? If so,
tell the community about your situation.
I don't believe adding another mandatory contact to the objects themselves helps anyone or anything as the scatter gun approach seems to always be used in a reporting process.
looking at the role account.
$ whois -h whois.apnic.net -- "-t role" % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
There exists an abuse-mailbox field does that not satisfy the need for those "more and more" organisations that are building abuse teams??
No it does not. Even the person object has an abuse-mailbox field. But the problem I have seen at RIPE is that we do one whois query for an IP address.
We get back 5 different abuse-mailbox fields with different abuse contact addresses. And RIPE has an IRT Object as well and some ISPs use description fields as well. So there is a bunge of addresses and nobody does know which is the right one.
The intention of this proposal is: 1.) Single point of information. 2.) Offer flexibility to netrange owners. 3.) Give Abuse Departments the chance to publish their information. 4.) Make parsing more effective.
The website lists:
"trouble | Can be used to include details on where to send abuse complaints."
and while it reflects a set of data:
And how do you parse this?
trouble: Don't send any abuse reports to abuse@domain.tld
or
trouble: Send abuse reports to abuse (at) domain (dot) tld
We have seen such constructs at RIPE for long and it does not help.
One point for all abuse information. To be honest I think after getting this proposal aknowledged there would be a perfect follow up to get rid of abuse-mailbox and of trouble fields because they are not neccessary any more.
- Do you see any disadvantages in this proposal?
Lets say you do add a mandatory abuse object to the inet(6)num/aut-num.
Since most allocations come with the text:
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This object can only be updated by APNIC hostmasters. remarks: To update this object, please contact APNIC remarks: hostmasters and include your organisation's account remarks: name in the subject line. remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
You are actually asking APNIC to update all of those allocation inet(6)nums with the extra object. Now lets assume you do automate that, fine. Every organisation that wants it changed now needs to "contact APNIC hostmasters", or are you asking the hostmasters to solicit that information?
IMHO this is nothing that has to be cleared in this proposal, but nevertheless this is a good question. After some other comments I started to think about a quiet different solution.
How about making the filed mandatory for new allocations. That would be not a problem. Let it open for existing allocations. That way you do not have the above mentioned problem. And the second and more important thing is, that you exactly know that the abuse-c fields are okay, because they are new. So data should be accurate.
In addition with another proposal of deleting trouble-fields and abuse-mailbox attributes will force lot's of poeple adding abuse-c fields. So they are new again. Last but not least finding a way of keeping the data accurate this would work perfectly in my opinion.
I'm going to guess (a cynical guess) that many organisations will not request the update to the automated addition of 'abuse-c:', leaving multiple superfluous contacts.
They are not superfluous. abusix started a test. We started an inofficial not public blacklist, which lists all abuse-contacts that are not working because the email address was bouncing. We offered that list to 5 ISPs and asked them to use this as a greylisting attribute. They did and the number of working email addresses at this ranges increased rapidly. ;-)
There is somebody in the world who would do the same what rfc-ignorant is doing for domains in this case for IPs.
- Is there anything in the proposal that is not clear?
"more and more" appears vague. do you have any statistics? (section 2)
We have a statistic about how many IP ranges do not have propoer abuse contact information. And we have a round 20 ISPs within APNIC asking us to change the address were we should send abuse reports to. But we are working automatically so we any many other reporters in the world would like to see the single point of abuse-contact in the SPNIC whois information.
I believe your disadvantages are understated. The examples above suggest that the whois data is not consistent to the whois schema. Adding a further change bites into a whois database consistency issue, that really shouldn't exist, but does where the APNIC secretariat will probably need to expend significant resources on rectifying, provided they have resources to spare.
The abuse-c is nothing else than an object somebody can link a handle (role or person) to. I can not see a problem with inconsistency.
- What changes could be made to this proposal to make it more
effective?
I can see where you are coming from, trying to make the contact process for abuse/fraud/crime easier is admirable. I just don't think this will make any positive difference.
It makes a difference for network owners that are willed to change things. And thank god there are a lot in the Asian/Pacific area. You will never be able to force network owners that are not interested in abuse handling with something like a APNIC proposal.
My idea of that is. The less bad network owners do, the worse they get. The more good network owners make a great job the better they get and the worse the bad ones get. So lets help the good ones to get better.
I would suggest that serious levels of contact information is not found in whois, and if you wanted to try to 'force' the information out of member organisations via the RIR I would suggest an RIR facilitated LEA or 'trusted entity' web portal that provides a deeper look into networks (under the conditions of the membership agreement) to be of more use as less organisations would redirect those contacts to /dev/null
Full Nack. I don't like trusted entity webportals. Because you will always need somebody to decide what ist trustworthy and what is not. And my feeling about trust might be different from yours and the others. So who should decide that?
As already mentioned above. We can not force anybody to be good. But we can help them who decided to be good to get better. This proposal is for all the APNIC network owners that send us emails and told us, that they wanna handle their abuse and asked us to change the addresses, because they have an abuse department, but no chance to publish their stuff in an appropriate way.
Thanks
Tobias
Hi Tobias,
On 30/01/2010, at 10:01 PM, Tobias Knecht wrote:
No it does not. Even the person object has an abuse-mailbox field. But the problem I have seen at RIPE is that we do one whois query for an IP address.
We get back 5 different abuse-mailbox fields with different abuse contact addresses. And RIPE has an IRT Object as well and some ISPs use description fields as well. So there is a bunge of addresses and nobody does know which is the right one.
Presumably in the situation you quote, would that not be the IRT object?
The danger I see in this proposal is another mailbox field (ether direct or inherited) which actually adds no clarity and falls into disuse.
are you proposing this in the ripe community? Or is IRT adequate there? (since you quote it in the policy but don't elude to effectiveness)
note that APNIC also has the IRT object.
terry$ whois -h whois.apnic.net -- "-t irt" % [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
The intention of this proposal is: 1.) Single point of information. 2.) Offer flexibility to netrange owners. 3.) Give Abuse Departments the chance to publish their information. 4.) Make parsing more effective.
I'm sure your intentions are genuine - I just don't agree that this policy will get you there.
The website lists:
"trouble | Can be used to include details on where to send abuse complaints."
and while it reflects a set of data:
And how do you parse this?
trouble: Don't send any abuse reports to abuse@domain.tld
or
trouble: Send abuse reports to abuse (at) domain (dot) tld
Fair point.. although I don't think i've seen the former example.
We have seen such constructs at RIPE for long and it does not help.
One point for all abuse information. To be honest I think after getting this proposal aknowledged there would be a perfect follow up to get rid of abuse-mailbox and of trouble fields because they are not neccessary any more.
so above you say "flexibility".. and here you say "simplification" (paraphrasing).
Maybe you can combine the approaches?
IMHO this is nothing that has to be cleared in this proposal, but
I disagree.. The results of this proposal requires APNIC to do *something*.
The extent of that *something* is not clear.
nevertheless this is a good question. After some other comments I started to think about a quiet different solution.
How about making the filed mandatory for new allocations. That would be not a problem. Let it open for existing allocations. That way you do not have the above mentioned problem. And the second and more important thing is, that you exactly know that the abuse-c fields are okay, because they are new. So data should be accurate.
So in a database schema you are actually making the field "optional" but institutionally recommended for new allocations.
In addition with another proposal of deleting trouble-fields and abuse-mailbox attributes will force lot's of poeple adding abuse-c fields. So they are new again. Last but not least finding a way of keeping the data accurate this would work perfectly in my opinion.
I look forward to your amended proposal.
I'm going to guess (a cynical guess) that many organisations will not request the update to the automated addition of 'abuse-c:', leaving multiple superfluous contacts.
They are not superfluous. abusix started a test. We started an inofficial not public blacklist, which lists all abuse-contacts that are not working because the email address was bouncing. We offered that list to 5 ISPs and asked them to use this as a greylisting attribute. They did and the number of working email addresses at this ranges increased rapidly. ;-)
Interesting.
There is somebody in the world who would do the same what rfc-ignorant is doing for domains in this case for IPs.
eeek.. but o.k..
"more and more" appears vague. do you have any statistics? (section 2)
We have a statistic about how many IP ranges do not have propoer abuse contact information. And we have a round 20 ISPs within APNIC asking us to change the address were we should send abuse reports to.
is that: 1) because they don't want to get the reports from you? or 2) because they _trust_ you and want you to have a good contact point, but not some 'others'?
But we are working automatically so we any many other reporters in the world would like to see the single point of abuse-contact in the SPNIC whois information.
how many reporters? and what is the breakdown of them, ie ISP, LEA, CERT, ABUSIX-type org??
(trying to understand the problem, and what percentage is about the allocation holder, and what percentage for making the lives of the reporters easier)
I believe your disadvantages are understated. The examples above suggest that the whois data is not consistent to the whois schema. Adding a further change bites into a whois database consistency issue, that really shouldn't exist, but does where the APNIC secretariat will probably need to expend significant resources on rectifying, provided they have resources to spare.
The abuse-c is nothing else than an object somebody can link a handle (role or person) to. I can not see a problem with inconsistency.
The inconsistency appears to exist already. It will no doubt cost resources to fix. (ie objects with attributes that don't conform to schema/templates) So in adding this new object, a prudent organisation would clean up the data they had already, or at least do so in the process of adding the abuse-c attribute.
I would suggest that serious levels of contact information is not found in whois, and if you wanted to try to 'force' the information out of member organisations via the RIR I would suggest an RIR facilitated LEA or 'trusted entity' web portal that provides a deeper look into networks (under the conditions of the membership agreement) to be of more use as less organisations would redirect those contacts to /dev/null
Full Nack. I don't like trusted entity webportals. Because you will always need somebody to decide what ist trustworthy and what is not. And my feeling about trust might be different from yours and the others. So who should decide that?
Trust in that space is a contractual item, and limited to those who are capable of meeting it. law enforcement agencies , national/state CERT teams, etc.
As already mentioned above. We can not force anybody to be good. But we can help them who decided to be good to get better. This proposal is for all the APNIC network owners that send us emails and told us, that they wanna handle their abuse and asked us to change the addresses, because they have an abuse department, but no chance to publish their stuff in an appropriate way.
So 20 ISPs? yeah (from above)? So you want to make a change that provides 20 APNIC members with use of abuse-c. (of a membership of 2000+ members?)
Terry
Hi Terry,
Presumably in the situation you quote, would that not be the IRT object?
The danger I see in this proposal is another mailbox field (ether direct or inherited) which actually adds no clarity and falls into disuse.
are you proposing this in the ripe community? Or is IRT adequate there? (since you quote it in the policy but don't elude to effectiveness)
note that APNIC also has the IRT object.
Yes the IRT Object would do it. Whenever I didn't notice that APNIC has an IRT object, because we have never seen an IRT Object in the APNIC Database.
The problem with the IRT Object is, that nobody knows what it is. We see that at RIPE every day. When we suggest people to publish one.
But to be honest I have to rethink this proposal if there is an IRT Object in place.
(1) There must be a future policy that talks about frequent update requests. (2) Why not making the IRT-Object mandatory. (That's what we will try at RIPE as well)
The website lists:
"trouble | Can be used to include details on where to send abuse complaints."
and while it reflects a set of data:
And how do you parse this?
trouble: Don't send any abuse reports to abuse@domain.tld
or
trouble: Send abuse reports to abuse (at) domain (dot) tld
Fair point.. although I don't think i've seen the former example.
whois 131.111.0.0/16 | grep remarks
Okay, it's not APNIC and it is not a trouble, but such things exist.
One point for all abuse information. To be honest I think after getting this proposal aknowledged there would be a perfect follow up to get rid of abuse-mailbox and of trouble fields because they are not neccessary any more.
so above you say "flexibility".. and here you say "simplification" (paraphrasing).
Maybe you can combine the approaches?
I would like to to. So if there are ideas on how we can put everything needed in one or 2 or 3 poroposals, I'm absolutly happy to do that.
IMHO this is nothing that has to be cleared in this proposal, but
I disagree.. The results of this proposal requires APNIC to do *something*.
The extent of that *something* is not clear.
Full-ACK, but does it make sense to define to have an update request for an abuse-c (IRT) and leave out the other fields? And does it make sense to add this request for all others roles and person objects into a proposal about abuse-c (IRT).
nevertheless this is a good question. After some other comments I started to think about a quiet different solution.
How about making the filed mandatory for new allocations. That would be not a problem. Let it open for existing allocations. That way you do not have the above mentioned problem. And the second and more important thing is, that you exactly know that the abuse-c fields are okay, because they are new. So data should be accurate.
So in a database schema you are actually making the field "optional" but institutionally recommended for new allocations.
No need to do make it mandatory in the databse schema. You can just make it mandatory in the application. But even that was just an idea.
In addition with another proposal of deleting trouble-fields and abuse-mailbox attributes will force lot's of poeple adding abuse-c fields. So they are new again. Last but not least finding a way of keeping the data accurate this would work perfectly in my opinion.
I look forward to your amended proposal.
Me too ;-)
"more and more" appears vague. do you have any statistics? (section 2)
We have a statistic about how many IP ranges do not have propoer abuse contact information. And we have a round 20 ISPs within APNIC asking us to change the address were we should send abuse reports to.
is that:
- because they don't want to get the reports from you?
or 2) because they _trust_ you and want you to have a good contact point, but not some 'others'?
It's about receiving loads of reports from us and others at a personal tech-c address.
But we are working automatically so we any many other reporters in the world would like to see the single point of abuse-contact in the SPNIC whois information.
how many reporters? and what is the breakdown of them, ie ISP, LEA, CERT, ABUSIX-type org??
There is a govermental project going on in Germany and spreading to Europe at the moment. This project calls any kind of institution that has abuse data available to share it with the responsible partner.
At the moment this project is aknowledged, but there are still some minor things to fix. So the things we (abusix) is doing is just a first step of what will hapen in future. There are already some ISPs testing their reporting mechanisms. But not really high volume.
I believe your disadvantages are understated. The examples above suggest that the whois data is not consistent to the whois schema. Adding a further change bites into a whois database consistency issue, that really shouldn't exist, but does where the APNIC secretariat will probably need to expend significant resources on rectifying, provided they have resources to spare.
The abuse-c is nothing else than an object somebody can link a handle (role or person) to. I can not see a problem with inconsistency.
The inconsistency appears to exist already. It will no doubt cost resources to fix. (ie objects with attributes that don't conform to schema/templates) So in adding this new object, a prudent organisation would clean up the data they had already, or at least do so in the process of adding the abuse-c attribute.
The same would happen if we make the IRT Object mandatory ?!?!
I would suggest that serious levels of contact information is not found in whois, and if you wanted to try to 'force' the information out of member organisations via the RIR I would suggest an RIR facilitated LEA or 'trusted entity' web portal that provides a deeper look into networks (under the conditions of the membership agreement) to be of more use as less organisations would redirect those contacts to /dev/null
Full Nack. I don't like trusted entity webportals. Because you will always need somebody to decide what ist trustworthy and what is not. And my feeling about trust might be different from yours and the others. So who should decide that?
Trust in that space is a contractual item, and limited to those who are capable of meeting it. law enforcement agencies , national/state CERT teams, etc.
IMHO that is not right. Trustlevels are a personal decisions. I have to decide who is trustworthy and who is not. Everybody has to do so. I do not want to have an internet that tells me and others who is trustworthy. I have to understand to goals of everybody to make the decsion if I wanna trust or not. And there are even governmental decisions or goals that won't fit in my personal world. So I will not support and trust these ideas. And why are we or you or anybody else less trustworthy than a cert or a governmental institution?
As already mentioned above. We can not force anybody to be good. But we can help them who decided to be good to get better. This proposal is for all the APNIC network owners that send us emails and told us, that they wanna handle their abuse and asked us to change the addresses, because they have an abuse department, but no chance to publish their stuff in an appropriate way.
So 20 ISPs? yeah (from above)? So you want to make a change that provides 20 APNIC members with use of abuse-c. (of a membership of 2000+ members?)
That's what we know about. And if these 20 ISPs can make a better job with this proposal, it's worth doing so. My opinion.
Thanks,
Tobias
Hi Terry,
Thanks for pointing out this discrepancy. We will fix the documentation accordingly. The APNIC whois reference manual is available here:
http://www.apnic.net/apnic-info/whois_search2/using-whois
Cheers, ________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Area Manager, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
On 30/01/2010 7:33 PM, Terry manderson wrote:
Note to APNIC:
The templates and the attributes at http://archive.apnic.net/db/ref/attributes/attributes-role.html (presumably archived but still the only whois documentation you have linked on the main website) do not agree!
The website lists:
"trouble | Can be used to include details on where to send abuse complaints."
and while it reflects a set of data:
ie:
role: Optus Internet address: Level 3, 11 Help Street address: Chatswood, NSW 2067 country: AU phone: +61-2-9027-1127 fax-no: +61-2-9027-1035 e-mail: oie-netops@optus.com.au trouble: Send spam/abuse reports to abuse@optusnet.com.au admin-c: OI1-AP tech-c: OI1-AP nic-hdl: OI3-AP notify: oie-netops@optus.com.au mnt-by: MAINT-AU-OPTUSINTERNET changed: oie-netops@optus.com.au 20040502 changed: hm-changed@apnic.net 20041020 changed: hm-changed@apnic.net 20041020 source: APNIC
it appears out of date with the whois schema.
Hallo everybody,
first of all thanks to all the people that have joined the discussion of this proposal.
There were loads of good ideas and I have learned a lot about different things.
I'm sorry that I have to say, that I made a mistake. I didn't know about the IRT-Object in the APNIC database. I knew about APNIC using the same DB as RIPE, but I thought the IRT was not implemented in the APNIC database. (Thanks to Terry Manderson)
With this knowledge my proposal would have been different. But it is not to late to change the actual proposal. But I want to summarize the discussed things and ask for your opinion and than change the proposal. Makes more sense and saves time.
The ideas that will follow are very similar to them we are working on for RIPE at the moment.
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory. The reason is: e-mail field is the contact address for humans and the abuse-mailbox field is the contact address for reports.
(3) Request frequent updates of the IRT-Object (or more) and "force" owners to publish correct data (check email addresses, ...).
(4) Make abuse-mailbox fields unavailable in every other role or person object. Because it's not needed anymore.
(5) Make trouble fields unavailable. Because it's not needed anymore.
How about this quit different version? And sorry again for not knowing about the IRT Object.
Thanks,
Tobias
Hi Tobias,
I agree to clarify the abuse POC. but your idea below, it seems to be many change the whois DB.
How about chang the "abuse-mailbox" field to be a mandatory? It will be able to implement with small change to whois DB.
-- Satoru Tsurumaki Softbank BB Corp.
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Tobias Knecht Sent: Monday, February 01, 2010 5:41 PM To: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
Hallo everybody,
first of all thanks to all the people that have joined the discussion of this proposal.
There were loads of good ideas and I have learned a lot about different things.
I'm sorry that I have to say, that I made a mistake. I didn't know about the IRT-Object in the APNIC database. I knew about APNIC using the same DB as RIPE, but I thought the IRT was not implemented in the APNIC database. (Thanks to Terry Manderson)
With this knowledge my proposal would have been different. But it is not to late to change the actual proposal. But I want to summarize the discussed things and ask for your opinion and than change the proposal. Makes more sense and saves time.
The ideas that will follow are very similar to them we are working on for RIPE at the moment.
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory. The reason is: e-mail field is the contact address for humans and the abuse-mailbox field is the contact address for reports.
(3) Request frequent updates of the IRT-Object (or more) and "force" owners to publish correct data (check email addresses, ...).
(4) Make abuse-mailbox fields unavailable in every other role or person object. Because it's not needed anymore.
(5) Make trouble fields unavailable. Because it's not needed anymore.
How about this quit different version? And sorry again for not knowing about the IRT Object.
Thanks,
Tobias
Hi Satoru,
that would be easier, but we will have the same problems again.
(1) unpopulated IRT Object. (2) more than 1 place for the real abuse contact. (3) possibility of unaccurate data.
I think this will be a lot of work for APNIC, but it would clean up the db quiet a bit and make things much clearer and easier.
Thanks,
Tobias
stsuruma@bb.softbank.co.jp schrieb:
Hi Tobias,
I agree to clarify the abuse POC. but your idea below, it seems to be many change the whois DB.
How about chang the "abuse-mailbox" field to be a mandatory? It will be able to implement with small change to whois DB.
-- Satoru Tsurumaki Softbank BB Corp.
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Tobias Knecht Sent: Monday, February 01, 2010 5:41 PM To: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
Hallo everybody,
first of all thanks to all the people that have joined the discussion of this proposal.
There were loads of good ideas and I have learned a lot about different things.
I'm sorry that I have to say, that I made a mistake. I didn't know about the IRT-Object in the APNIC database. I knew about APNIC using the same DB as RIPE, but I thought the IRT was not implemented in the APNIC database. (Thanks to Terry Manderson)
With this knowledge my proposal would have been different. But it is not to late to change the actual proposal. But I want to summarize the discussed things and ask for your opinion and than change the proposal. Makes more sense and saves time.
The ideas that will follow are very similar to them we are working on for RIPE at the moment.
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory. The reason is: e-mail field is the contact address for humans and the abuse-mailbox field is the contact address for reports.
(3) Request frequent updates of the IRT-Object (or more) and "force" owners to publish correct data (check email addresses, ...).
(4) Make abuse-mailbox fields unavailable in every other role or person object. Because it's not needed anymore.
(5) Make trouble fields unavailable. Because it's not needed anymore.
How about this quit different version? And sorry again for not knowing about the IRT Object.
Thanks,
Tobias
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
Hi Tobias,
-----Original Message----- Hi Satoru,
that would be easier, but we will have the same problems again.
(1) unpopulated IRT Object.
yes. but I counld't estimate of these impact, how many members are use IRT object, how much spent to unpopulate it, etc.. We need a comment from APNIC staff about these operations.
(2) more than 1 place for the real abuse contact.
The description of e-mail field in 'whois -h whois.apnic.net -- "-v person" ' say that e-mail address in a Person Object seems to be filtered if abuse-mailbox is not NULL. (umm,Is it correct?) Is it not enough?
(3) possibility of unaccurate data.
I think this issue are not solved by both your proposal and my idea.
regards,
Satoru Tsurumaki Softbank BB Corp.
I think this will be a lot of work for APNIC, but it would clean up the db quiet a bit and make things much clearer and easier.
Thanks,
Tobias
stsuruma@bb.softbank.co.jp schrieb:
Hi Tobias,
I agree to clarify the abuse POC. but your idea below, it seems to be many change the whois DB.
How about chang the "abuse-mailbox" field to be a mandatory? It will be able to implement with small change to whois DB.
-- Satoru Tsurumaki Softbank BB Corp.
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Tobias Knecht Sent: Monday, February 01, 2010 5:41 PM To: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
Hallo everybody,
first of all thanks to all the people that have joined the
discussion
of this proposal.
There were loads of good ideas and I have learned a lot about different things.
I'm sorry that I have to say, that I made a mistake. I didn't know about the IRT-Object in the APNIC database. I knew about
APNIC using
the same DB as RIPE, but I thought the IRT was not
implemented in the
APNIC database. (Thanks to Terry Manderson)
With this knowledge my proposal would have been different. But it is not to late to change the actual proposal. But I want to summarize the discussed things and ask for your opinion and than change the proposal. Makes more sense and saves time.
The ideas that will follow are very similar to them we are
working on
for RIPE at the moment.
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory. The reason is: e-mail field is the contact address for
humans and the
abuse-mailbox field is the contact address for reports.
(3) Request frequent updates of the IRT-Object (or more)
and "force"
owners to publish correct data (check email addresses, ...).
(4) Make abuse-mailbox fields unavailable in every other role or person object. Because it's not needed anymore.
(5) Make trouble fields unavailable. Because it's not
needed anymore.
How about this quit different version? And sorry again for not knowing about the IRT Object.
Thanks,
Tobias
sig-policy: APNIC SIG on resourcemanagement policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hello all,
IRT object has never been formally introduced to the APNIC community, hence the absence of any reference to it on our public website. There was an invitation in 2003 to discuss it in APNIC meetings, but the interest was pretty low at that time.
Having said that, APNIC whois which is based on RIPE's whois software has a built-in support for IRT objects.
We currently have 0 (none) irt object registered in APNIC database.
APNIC secretariat is following this discussion closely and will, as usual, implement what the community decides.
Cheers, ________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Area Manager, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
On 2/02/2010 2:54 PM, stsuruma@bb.softbank.co.jp wrote:
Hi Tobias,
-----Original Message----- Hi Satoru,
that would be easier, but we will have the same problems again.
(1) unpopulated IRT Object.
yes. but I counld't estimate of these impact, how many members are use IRT object, how much spent to unpopulate it, etc.. We need a comment from APNIC staff about these operations.
(2) more than 1 place for the real abuse contact.
The description of e-mail field in 'whois -h whois.apnic.net -- "-v person" ' say that e-mail address in a Person Object seems to be filtered if abuse-mailbox is not NULL. (umm,Is it correct?) Is it not enough?
(3) possibility of unaccurate data.
I think this issue are not solved by both your proposal and my idea.
regards,
Satoru Tsurumaki Softbank BB Corp.
I think this will be a lot of work for APNIC, but it would clean up the db quiet a bit and make things much clearer and easier.
Thanks,
Tobias
stsuruma@bb.softbank.co.jp schrieb:
Hi Tobias,
I agree to clarify the abuse POC. but your idea below, it seems to be many change the whois DB.
How about chang the "abuse-mailbox" field to be a mandatory? It will be able to implement with small change to whois DB.
-- Satoru Tsurumaki Softbank BB Corp.
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Tobias Knecht Sent: Monday, February 01, 2010 5:41 PM To: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
Hallo everybody,
first of all thanks to all the people that have joined the
discussion
of this proposal.
There were loads of good ideas and I have learned a lot about different things.
I'm sorry that I have to say, that I made a mistake. I didn't know about the IRT-Object in the APNIC database. I knew about
APNIC using
the same DB as RIPE, but I thought the IRT was not
implemented in the
APNIC database. (Thanks to Terry Manderson)
With this knowledge my proposal would have been different. But it is not to late to change the actual proposal. But I want to summarize the discussed things and ask for your opinion and than change the proposal. Makes more sense and saves time.
The ideas that will follow are very similar to them we are
working on
for RIPE at the moment.
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory. The reason is: e-mail field is the contact address for
humans and the
abuse-mailbox field is the contact address for reports.
(3) Request frequent updates of the IRT-Object (or more)
and "force"
owners to publish correct data (check email addresses, ...).
(4) Make abuse-mailbox fields unavailable in every other role or person object. Because it's not needed anymore.
(5) Make trouble fields unavailable. Because it's not
needed anymore.
How about this quit different version? And sorry again for not knowing about the IRT Object.
Thanks,
Tobias
sig-policy: APNIC SIG on resourcemanagement policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
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
Hi there,
IRT object has never been formally introduced to the APNIC community, hence the absence of any reference to it on our public website. There was an invitation in 2003 to discuss it in APNIC meetings, but the interest was pretty low at that time.
Having said that, APNIC whois which is based on RIPE's whois software has a built-in support for IRT objects.
We currently have 0 (none) irt object registered in APNIC database.
APNIC secretariat is following this discussion closely and will, as usual, implement what the community decides.
Lets make it mandatory with a mandatory abuse-mailbox field. So this is nothing that could not been implemented in a short period. And nobody will be hurt. That way the actions that has to be taken is really small and we can concentrate on data accuracy.
That way we would as well fix the things mentioned by me. Flexibility, because there is a dedicated abuse contact object. In a combination of deleting abuse-mailbox in all other objects than IRT and deleting all trouble fields, the single point of contact and a good cleanup of the whois database.
Thanks,
Tobias
Tobias,
I hate to be a stickler for process (god forbid!) but I'm guessing that either prop-79 needs to be withdrawn, or replaced with a proposal that covers your request below (or both)..
Cheers Terry
On 02/02/2010, at 5:24 PM, Tobias Knecht wrote:
Hi there,
IRT object has never been formally introduced to the APNIC community, hence the absence of any reference to it on our public website. There was an invitation in 2003 to discuss it in APNIC meetings, but the interest was pretty low at that time.
Having said that, APNIC whois which is based on RIPE's whois software has a built-in support for IRT objects.
We currently have 0 (none) irt object registered in APNIC database.
APNIC secretariat is following this discussion closely and will, as usual, implement what the community decides.
Lets make it mandatory with a mandatory abuse-mailbox field. So this is nothing that could not been implemented in a short period. And nobody will be hurt. That way the actions that has to be taken is really small and we can concentrate on data accuracy.
That way we would as well fix the things mentioned by me. Flexibility, because there is a dedicated abuse contact object. In a combination of deleting abuse-mailbox in all other objects than IRT and deleting all trouble fields, the single point of contact and a good cleanup of the whois database.
Thanks,
Tobias
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
Hi,
sorry for the delayed answer. The APNIC Secretariat is working on a revised version of the policy. This will be published soon.
Thanks,
Tobias
Terry Manderson schrieb:
Tobias,
I hate to be a stickler for process (god forbid!) but I'm guessing that either prop-79 needs to be withdrawn, or replaced with a proposal that covers your request below (or both)..
Cheers Terry
On 02/02/2010, at 5:24 PM, Tobias Knecht wrote:
Hi there,
IRT object has never been formally introduced to the APNIC community, hence the absence of any reference to it on our public website. There was an invitation in 2003 to discuss it in APNIC meetings, but the interest was pretty low at that time.
Having said that, APNIC whois which is based on RIPE's whois software has a built-in support for IRT objects.
We currently have 0 (none) irt object registered in APNIC database.
APNIC secretariat is following this discussion closely and will, as usual, implement what the community decides.
Lets make it mandatory with a mandatory abuse-mailbox field. So this is nothing that could not been implemented in a short period. And nobody will be hurt. That way the actions that has to be taken is really small and we can concentrate on data accuracy.
That way we would as well fix the things mentioned by me. Flexibility, because there is a dedicated abuse contact object. In a combination of deleting abuse-mailbox in all other objects than IRT and deleting all trouble fields, the single point of contact and a good cleanup of the whois database.
Thanks,
Tobias
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
On 1 Feb 2010, at 12:41, Tobias Knecht wrote:
[...]
(1) Make the IRT-Object mandatory.
(2) Make the abuse-mailbox field within the IRT-Object mandatory.
What would be the consequence for not providing an IRT object and populating its abuse-mailbox field?
Regards,
Leo Vegoda
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/proposalsRandy, Ching-Heng, and Terence
prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________
Author: Tobias Knecht tk@abusix.org
Version: 1
Date: 29 January 2010
- 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.
- 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.
- 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]
- 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 objectOn 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
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.
- 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.
- 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
You are absolutely right. 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/proposalsRandy, Ching-Heng, and Terence
prop-079-v001: Abuse contact information (abuse-c) ________________________________________________________________________
Author: Tobias Knecht tk@abusix.org
Version: 1
Date: 29 January 2010
- 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.
- 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.
- 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]
- 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 objectOn 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
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.
- 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.
- 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
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
Activity Summary
- 4987 days inactive
- 4987 days old
- sig-policy@lists.apnic.net
- 12 participants
- 24 comments