j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
- 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 email@example.com
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
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.