<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I would prefer to have an option to provide either an abuse POC _OR_ a machine readable abuse URI. Both should be allowed, but if an abuse URI is permitted, it no longer makes sense to require anyone providing an abuse URI to also provide an abuse POC.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2022, at 10:17 , Amy Potter <<a href="mailto:amybpotter@gmail.com" class="">amybpotter@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi all,</div><div class=""><br class=""></div><div class="">Just wanted to check in with the community to see if there is any feedback on our latest draft of 2021-7. We've adjusted the language to clear up the problem statement and clarify that an optional abuse field for a machine-readable URI will be added to the abuse POC.<br class=""></div><div class=""><br class=""></div><div class=""><p class=""><strong class="">Problem Statement:</strong></p><p class="">The current abuse contact fields are not sufficient for the abuse reporting mechanisms most frequently used today. For many network providers, the process for dealing with network abuse usually starts with a web page. The web page provides instructions and may offer forms for describing the abuse and uploading supporting material of the nature that the service provider needs in order to take action. It would be helpful for these organizations if the abuse contact had a specific field for a machine-readable abuse URI.</p><p class=""><strong class="">Policy statement:</strong></p><p class="">Section 2.12- add “Organizations may provide an optional machine-readable abuse URI for reporting abuse” to end of paragraph.</p><p class="">Section 4.2.3.7.3.2: add “and may have an optional machine-readable abuse URI” after “Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs” so the sentence reads…</p><p class="">“Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs and may have an optional machine-readable abuse URI visible on the WHOIS or Distributed Information Service record for that block.”</p><p class="">Section 6.5.5.3.1: add “and may have an optional machine-readable abuse URI” after “Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs” so that the sentence reads</p><p class=""> “Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs and may have an optional machine-readable abuse URI visible on the WHOIS or Distributed Information Service record for that block.”</p>
</div></div>
_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>