Hi,
Lets say order the relevant technical processes should be included in this proposal (Some might call this a plan).
I will ask RIPE NCC to join this discussion since I can not talk about implementation in behalf of RIPE NCC. In my opinion it does not make any sense to include implementation details into an policy. Two reasons for that. Nobody cares about the implementation details in 10 years when things are in place. This would pollute the policy. And second, what happens if another proposal coming up in 5 years changes the whole design of database? Policy is policy and implemetation details are implementation details. I agree that RIPE NCC should publish their ideas, but not put it into the proposal text. And an example at the end. If we agree that we have to be in London on 10th of December. We agreed on that. If RIPE NCC tells us to walk and swim, we can say "No way!" and ask them if we could fly, but we do not disagree about being in London. I do not want to mix up the fact of going to London (introducing the abuse-c) with the fact on how to go to London (how to implement things).
Another point: if the general idea of the policy is acceptable, wouldn't it be nice to have 2 abuse mailboxes: one for humans, one for bots?
+1;
Having two contacts might complicates things, it might be complicated for the end user to decide wich one to contact.
No. End users should not take the way of whois. They should use the abuse finder tool. This tool will give them exactly what they need.
Maybe it would be easier to make one contact wich has to be marked as "person", "role" or "robot". Both, end user or automatic reporting tools, could then decide themself, if the type of the contact fits their intention. It might also be nice to have a "preferred reporting method" field included, what could be "email, phone, url, ARF, X-ARF" or similar.
This will make things much more complicated. I agree and we had a discussion about this in the Task Force as well, that a url may be an option as well. On the other hand, parsing email in a standard format is not that difficult and in the abuse community offering a form to report abuse is most likely seen as a "Fuck off!" to the reporter. The idea behind abuse-mailbox and e-mail attribute is the following: The email attribute can be personal information, so you do not want to publish it unrestricted. The information in the abuse-mailbox attribute will be not personal information and can be queried unrestrictedly. If you have no need for a differentiation between those, take the same address for both. That would be absolutely fine.
What if the people or robots reporting to such an address, don't care about robot vs. human mailboxes and/or relevant reporting formats (or are reporting bogus due to bugs)? I would suggest, that every team/member/robot behind such an address should figure that for themselves.
There is a second reason for differentiation. Spam filters on abuse addresses do not make a lot of sense. But spam filters on a team addresses read by humans do make a lot of sense. What if a bot does not care. He will take care, because if he sends the reports to the personal address they will get lost, because the spam filter will take care of them. I'm against every team/member/robot should figure that out themselves. That is exactly the situation at the moment with loads of opportunities. Receiving all kinds of robot reports on one mailbox (abuse-mailbox) is already best practice today. So this is nothing new. A last reason why I would not split up things to far. I want to avoid adding to much opportunities at once. I think there is not reason not to add Jabber/IRC/XMP-PRC/whatever as a new attribute as soon as it shows up and is widely used. At the moment mail is the most common way of exchanging reports about abusive behavior. So that is why I would suggest to stay with email and see if something really new comes up. Thanks, Tobias -- abusix