Hi everybody,
Accepting the assumption it was hard for resource holders/maintainers to find the right attribute/object type to publish abuse contact information, this can be well achieved with abuse-c. But the various examples provided in this and other threads suggest that more differentiation is needed for the communication channels. An abuse-c target object should inherit most of its attributes from the role: object and should offer different ways of reporting: manual (email), automated (email) and, maybe, web forms and the likes. Note, the idea was to help resource holders communicate their preferred way of contact establishment, _not_ to dictate or discriminate against their abuse handling procedures.
Sounds like a good suggestion. Imho the Best Practice for reporting abuse issues is e-mail for several good reasons. That's why I decided to stay with e-mail in this proposal. If there is any other Best Practice out there that tells us to add an attribute for webforms please let me know and I will add it to the proposal as an optional field in addition to e-mail and abuse-mailbox attributes.
And again, still assuming the idea is to help resource holders publish their data, there is no need to make "abuse-c" mandatory -- simply because the idea is so crisp and brilliant that they will adopt quickly.
Even if I fully agree with your statement about the crisp and brilliant proposal ;-) I do not agree with your other statement. I think the abuse-c should be mandatory for several good reasons I already brought up on this list. I also agree that there are several reasons for not making it mandatory, but the brilliance of this proposal is probably not one of them.
On item (1b) above, the proposal is unclear about the target audience for the "abuse-c" object on the receiving side.
It is all of the following.
Is it the end user who - regularly or occasional - sends some report? These folk can use the abuse finder tool today and they should really not be exposed to the raw database output anyway. Whatever change is applied, it will need a tool with additional explanation and guidance.
Absolutely agree with the additional explanation and guidance. The Abuse Finder Tool is the Tool to use for this audience. Never the less to come back to the "mess" the Abuse Finder can not find all entries in the Database just because there is no way to parse free text in an 100% correct way. And to be honest needing up to 150 queries to get one email address is far away from not being a "mess". Please recognize, that I have not put this specific issue in the proposal, because it has nothing to do with the idea of the proposal itself. Never the less it shows that this proposal would also be a huge improvement when it comes to maintenance and development for RIPE NCC and the functionality and reliability of the Database which should be and hopefully is the most important issue.
Is it for inter-operator incident handling? In this case, the relation to the IRT object needs to be clarified. That aside, people would probably expect manual or semi-automated (as in: ticketing system) handling of the incident report. Still, the current abuse-finder tool can already be of significant help.
As already stated in another mail on this mailinglist the IRT Object is another Object that has not direct connection to the abuse-c. Of course there will be maintainers that feel, that the abuse-c is a copy of the IRT and makes data redundant. Since we have seen numbers of IRT Object published there is absolutely no doubt about, that the future of the IRT Object has to be discussed. Whether if it will be removed, stays like it is or will be pushed more with documentation and "IRT Object Marketing". But this is and will not be part of this discussion.
Is it for high volume automated report dissemination (trap or sensor initiated identification of "activity")? For this to work it needs automated handling on the receiving side and it should be clearly opt-in, so that the receiving entity can prepare for proper processing.
Disagree from my experience in the anti-abuse industry. First of all reporting must be easy and receiving reports must be easy as well. That's why opt-in is a bad idea, which can bee seen at feedbackloops. Second, if you do not want to receive reports from one party, block them or directly delete them. That is best practice and widely adopted and really not complicated to do. Not even talking about the huge amount of work and maintenance that is needed to keep up a opt-in infrastructure and to find the right data sources.
To summarize: who is the target audience and what mode of operation are resource holders going to subscribe to by publishing an "abuse-c" reference?
The target audience is the reporter and the receiver. The reporter will find the responsible address more easy and the receiver can publish his information more easy. By publishing the abuse-c the receiver subscribes to his already existing duty to keep his network clean and avoid abusive behavior. I hope all people here agree to this.
Item (2) above, no rate limiting on the responses, is also tricky. This is much more about the actual access mechanism than the object type and its attributes and the policy text (cf 'arguments opposing this proposal') already states that a proposal with the devil in the details and the details not laid out doesn't really make sense.
It is about the possibility to access the abuse-c without query restrictions. As a policy proposer I do not care about the implementation, I care about functionality. And if this functionality is not possible in the RIPE DB, RIPE NCC will mention this in the impact analysis. If it is possible they will probably implement it as soon as this proposal reached consensus.
And quite frankly, postponing this to the result of the NCC impact analysis is putting the cart before the horse. Details,please - and that also covers the proposed inheritance function.
Same here. We are talking about the goal and not the way at the moment. If we decide that we have the same goal we can talk with RIPE NCC about the way to get there and find a way that suits (mostly) all parties.
Then, finally, why should the "abuse-c" object, or the references to it, respectively, be mandatory (noting that version 2 claims it's mandatory for aut-nums only, again without giving deeper insight)?
It will be mandatory for aut-nums, inetnums and inet6nums. I have seen that there is something missing in the proposal text and I'm sorry for that. It will be mandatory for aut-nums, inetnums and inet6nums. I will try to get it fixed in this version or at least in the next version. Thanks for pointing this out.
However, I have read between the lines (or maybe even explicit) that some are dreaming of creating compliance cases at high volume, probably to get address space eventually revoked. I am unconvinced that this reflects the community cooperation that we celebrated happening the last 2+ decades. In any event, if that's the end goal, the proposal should be honest about this, but I think it's the wrong way to go.
I was reading the hole proposal, which was written by me, again a few seconds ago just to make sure I fully understood it. I have not seen anything about revoking address space and a possibility that high volumes lead to any kind of punishment. Not explicitly and not between the lines. Honestly (as honest as the proposal itself) reading between the lines and to fan fear are imho not good arguments against this proposal. Sorry. However the idea of revoking ip space based on high level complaint rates may be dreamed by some people, but there would be still a policy proposal necessary to go down this road and I think if this proposal shows up we can disagree there. I hope I was able to clear some stuff up and make it more clear what this proposal is about and about which parts we should discuss now. Thanks, Tobias