Hi,
I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
It's not only about the conclusion. As Frank stated there are some legal obligations in between. I do not want to go any deeper here, because I'm not a lawyer :-) The second point is that we probably only force less then 3% of the holders of direct allocations. More than 96% of them have already abuse contacts in place, unfortunately in different and ugly to parse places. I think there must be at least one abuse contact available for every ip address. And the proposal does not care about the place in hierarchy, but the "highest" place should offer one.
I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
I guess we are all neat freaks :-) I'm not sure what your definition of cleaning is. But there is a clean up planned in the impact analysis. Unfortunately the mess is too big to completely clean it up before coming up with new things. The idea is to transfer as much information as possible automatically into the new framework. The things that can't be cleaned up automatically (remarks:) must be cleaned by the resource holders themselves. But just cleaning them up would result in less maybe valuable data in the database. So it is much better than having the new thing in place and ask for a transfer from old to new. That way we will not loose data. It would not make sense to delete all old things and than come up with a new. If cleaning up in your definition means the data accuracy, even than I would prefer the proposals way. By asking to transfer the data accuracy will be increased without anything special, because all the accidentally wrong, forgotten, misspelled,... objects will be updated. In an next step we have to find ways how we can increase data accuracy and how we can keep it on a good level. Which will be another proposal. Talking now about data accuracy would bring us into the situation to left out the abuse contact information, because there are plans that it get's changed (with this proposal) and brings us into the situation of not exactly knowing what we have to handle, because we do not exactly know what we are coming up with.
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore. I do not want to encourage the development of more business logic like this. You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting …
By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger.
While thinking about the points here Frank and Denis sent their mails and the points they brought up are fitting perfectly, so I do not have to write anything here, because I agree fully with their argumentation. Thanks Frank. Thanks Denis. Thanks, Tobias