Hi Owen, all,
Responding in-line as [Jordi] Saludos, Jordi @jordipalet El 27/10/21 8:06, "Owen DeLong" <[email protected]> escribió: On Oct 26, 2021, at 15:17 , JORDI PALET MARTINEZ via ARIN-PPML <[email protected]> wrote: Hi, Unless I misunderstood this proposal, I believe this is the wrong way to go. Is this proposal suggesting that the abuse email must not be used anymore and instead a URL for abuse reports enforced? You are making the same mistake as the previous poster. You are assuming that a URL is a website locator. It is not. It can be an email, a website, a phone number, a file download, or any of a number of other resource types. [Jordi] What I’m saying is that IT MUST BE an email. It is impossible if *every* resource holder can decide a different way, it is impossible to automate the reporting systems. Also changing from the actual system to a “mailto” URL means that the existing apps need to be modified, as those are, in many cases, taking the abuse-mailbox field “as is”. As I read the proposal, the effect would be that administrators receive additional flexibility in how they want to receive abuse reports by being able to express that desire in terms of a URL. [Jordi] If we want additional flexibility and not impact on existing systems/apps, we should a) keep the existing abuse-mailbox as mandatory (just a plain email) and b) ADD other fields (as optional), or a single “multifunctional URL field”, etc. If you are currently using an abuse POC of [email protected] then you would be able to switch to mailto:[email protected] and continue as before. Arguably, staff should automatically convert all ABUSE POC records accordingly as part of the implementation process… Possible process (just spitballing here as this is operational and not part of the policy): [Jordi] Yes agree this is a very easy to implement thing for the staff, but who will pay for the job of changing existing apps in THE REST OF THE WORLD? Changes in this affect every possible abuse reporter that has automated it, not just resource holders in a given region. This is totally against what the other 4 RIRs have been doing for many years. Yes, it can be done, differently in every RIR, but it is going against the rest of the worldwide community. T+0 Policy is ratified by BoT T+120 days ARIN Staff has the software and training changes ready to go and the final schedule and process are documented and distributed arin-announce, nanog, other usual suspects… T+120 days ARIN begins accepting ABUSE-URLs as an additional field in WHOIS ORG and RESOURCE records. T+150 days ARIN Sends out warning that ABUSE-C will be removed from WHOIS at T+180 days T+165 days ARIN sends out second warning T+175 days ARIN sends out third warning T+178 days ARIN sends out fourth warning T+179 days ARIN sends out final warning T+180 days, ARIN converts all ABUSE-C items in records that lack an ABUSE-URL entry to ABUSE-URL: mailto:<former abuse-c content> ARIN then removes all remaining ABUSE-C fields from WHOIS If you look at all the other 4 RIRs, this is totally contrary to the practical experience. Only if you stick to your above erroneous assumption that an email address expressed in URL form is somehow less valid than an email address in an ABUSE-C field. If you enforce abuse to use a form, because each ISP can implement a totally different form format, this disallows automating the abuse reporting process, which is the only way it can be actually useful. This depends on your definition of useful. From a reporter perspective, perhaps automating the abuse reporting process to minimize the effort required to report abuse is most useful. [Jordi] Yes, but you’re missing the point on who must pay for the cost of abuse cases. Who is getting the profit from a customer? If you’re an ISP or university, and from your network you’re abusing my customers/my network, why I should bear the cost of reporting beyond a very simple and inexpensive way (that already exist in both open source and commercial systems)? Exactly the same in the other way around. If my customer is abusing your network/your customers, why you should pay for the cost of reporting the abuse beyond automated systems that already exists? Why any of us should invest in human filling or automatically filling the forms that *are* different for every resource holder in the world? >From a dealing with the abuse and solving the problem perspective, however, >there is some amount of value in having a standardized format for receiving >the reports and an ability to insist upon collecting the data needed to >actually act on the report. Allowing resource holders to choose how they wish to receive abuse reports, therefore, may have some utility. The problem is not that the abuse mailbox is not useful because it can get spam or something else, the problem is when it is not correctly processed, updated with the right contact, etc., so it must be periodically validated to become useful. There are multiple problems. Spam and other useless email flooding an abuse mailbox is, in fact, a real problem, so you can’t say that the problem is not that. You may say that’s not the problem that bothers you the most, but that’s a different statement entirely. There are also situations where incorrect processing is a problem. In many of those cases, it may well be because the needed information is not provided in the emailed report and many such emailed reports do not provide a functional way to request the additional information. There are, of course, other causes for this issue as well. Certainly stale data in WHOIS is a chronic problem and validation helps, but I don’t see URL validation as being significantly worse than email validation. Alternatively, reporting could be done using via email and standard formats such as X-ARF/RFC5965/RFC6650. That wouldn’t hurt, but even with standardized email formats, there are going to be bad implementations, errors, etc. that result in non-actionable reports. [Jordi] The we should improve it, but X-ARF and so on, allow using simple email for reporting any kind of abuse. There are already open source and commercial tools that handle it. It is just a matter of a) policy in each RIR to mandate it, b) parallel work (if needed) in IETF to make it better. APNIC and LACNIC have already implemented my abuse-c policy proposal that enforces the validation of the abuse-mailbox, and the results are awesome. I’ve heard mixed reviews, but glad you’re happy. [Jordi] The info that I’ve (top of my head, not precise data) is that the validation in APNIC for 90% of the abuse contacts took about 18 months, while in LACNIC only took 6 months for 85%. I’ve already noticed, reporting (mainly automatically) about 1.000-1.500 cases per day, that the number of bounces from those two regions decreased very quickly. As a consequence, the RIRs are also getting less reports themselves because now the reports are reaching the actual resource holder. I call it a success. It reached consensus also in AFRINIC but there is a pending appeal. It seems anything that happens in AFRINIC these days gets appealed. I wonder if the appeal committee will ever stop churning long enough to actually review any of the appeals that have been stacking up. [Jordi] Following the PDP, this appeal has already failed (because there are several procedural mistakes in the appeal itself – some missing steps according to the PDP that invalidate it), so the policy should be implemented (it will take anyway 3-6 months probably), but we need to wait for the AC to say that. Of course, now that the board has chosen to ensure that the appeal committee can’t possibly be independent or fair and is just an extension of the board, I’m not sure what the point is, just let the board ratify or not as the appeal committee has been rejiggered to ensure that they will do whatever the board wants anyway. The level of corruption and disdain for the community and the multistakeholder process displayed by the current AFRINIC board is truly outrageous. Hopefully the next election will see a great deal of new blood seated. [Jordi] While I don’t agree in many things with the board, and I expressed it publicly, regardless of what AC is there, the PDP has not been followed in order to make the appeal valid (and the time to re-appeal has passed). Anyway, this is a different discussion. In the case of RIPE NCC, there is already a validation policy in place. I tried to improve it, but didn’t reached consensus (yet). Certainly all of the abuse problems in Europe have been completely solved by this, right? [Jordi] Not all, however, it is clear that we have less than before and that’s why I think the policy should be improved, and I will keep working on that. Most of my abuse cases was coming at some point from France, Brasil, China and US. Not in any specific order. However now I get less and less from France, Brasil and China, and more and more from US (which often is never resolved, so we need to block US IP ranges and more and more people is doing that). This proposal will not improve that, in the other way around! Owen ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
