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