j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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:
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: email@example.com trouble: Send spam/abuse reports to firstname.lastname@example.org admin-c: OI1-AP tech-c: OI1-AP nic-hdl: OI3-AP notify: email@example.com mnt-by: MAINT-AU-OPTUSINTERNET changed: firstname.lastname@example.org 20040502 changed: email@example.com 20041020 changed: firstname.lastname@example.org 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