> On Oct 27, 2021, at 09:51 , David Farmer via ARIN-PPML <[email protected]> > wrote: > > And "tel:123-456-7890" is a URL for a phone number. However, that means to > replace the current POC info you need at least two URLs and probably more if > you want to support a web form and possibly an API option. But I don't > believe a single URL is a viable solution.
Most abuse POCs don’t have phone numbers (it’s not a required field). Most are role type POCs and so don’t have a name. In reality, the only meaningful field in most abuse POCs is the email. > But then, with multiple URLs there becomes a question of order of preference. > Which does the entity providing the URLs prefer and in what order? > Furthermore, if you provide only a Web Form or API URL, where do you call or > email if it seems to have gone wrong? I have no problem with the idea of ABUSE-URL being a repeatable field (1 or more allowed). If email isn’t working and the abuse POC has no phone number, where do you call or email today? > Simply changing the Abuse Contact to a URL isn't necessarily going to make > things better, and it could make things much worse. While this could allow > those that want to be responsive to increase their responsiveness, however, I > fear that it also allows those that want to be unresponsive to obfuscate > things even more than is possible today. An email address that leads to /dev/null attached to a role POC as an abuse contact is pretty well obfuscated today. I don’t see how a URL makes that more of a problem. > Having staff translate the current POC data to URLs is a reasonable > transition strategy on the data production side of things. But a flag day on > the data consumption side, would be unacceptable, at least in my opinion. So, > there would need to be an overlap where both the Abuse POC and Abuse URL Data > are available, and I think we are talking about multiple years of overlap. > Further, for at least for part of that time those that want to provide only > an Abuse URL would still need to provide an Abuse POC. I suppose on the consumption side, you can ignore the flag day if you want, but on that day, the production side will stop supplying the data you are thinking you are consuming, so… If you look at the timeline I proposed, there is, in fact, an overlap defined. I’m fine with changing the number of days at any of the various stages of the timeline if you feel that my straw man provided insufficient overlap. The time delta between the first day when ABUSE-URLs can be put into the system and the day when ARIN finally deletes the ABUSE-POC fields is, in fact, the overlap period you are describing. But there still has to be a flag day at some point when ABUSE-POC is no longer required or provided in the database or there’s not really much point. > There are many users of the current Abuse POC, and an abrupt change in the > format of this data is not acceptable in my opinion. So, while I support work > in this area, some changes are most definitely needed, and long-term this > seems like the right direction, nevertheless, we need to proceed very > carefully. Therefore, without at least a more detailed and lengthy transition > plan, I can not support any proposal that effectively eliminates the Abuse > POC as we know it today. I would support the addition of a URL option, > without the elimination of the Abuse POC at this time. Who said anything bout an abrupt change? I support a detailed transition plan and we can discuss how long is useful vs. useless (e.g. I think 180 days is probably too quick even though that’s what I put in my straw man to start the discussion, but I think that 20+ years is definitely too slow as proven by the current state of IPv6 deployment). Owen _______________________________________________ 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.
