Re: [sig-policy] prop-079: Abuse contact information (abuse-c)
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 at domain dot 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?)