<html><head></head><body>I see it as orthogonal, but YMMV.<br><br>I'd very much like the RIRs to have bigger sticks.<br><br>However, I don't know of any proposal or idea, current or historical, for said stick(s) that is or has been acceptable to a sufficiently broad cross-section of the membership to get any traction. :-(<br><br>(Nor am I about to suggest anything new, even if I had a new idea, as I don't need to get flamed that much this month.)<br><br>-Adam<br><br><div class="gmail_quote">On August 5, 2019 3:54:53 p.m. CDT, David Farmer <farmer@umn.edu> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div dir="ltr">I think you are making my point for me, currently, there aren't even theoretical consequences for ignoring the RIR system, even deliberately using someone else's allocations on the Internet, let alone using bogons. If you deliberately use someone else's allocations the RIR system currently continues to protect your allocations, even though you are thwarting the system. This is a form of "free-riding", you are enjoying the protection provided by the RIR system that is honored by many if not most operators, without honoring the protection it should be providing to others. I think those that deliberately thwart the system should lose the protection of the system. </div><div dir="ltr"><br></div><div dir="ltr">In my opinion, this is how ARIN grows the bigger stick you seem to be saying it needs. ARIN and the other RIRs only have the sticks that we give them. If you think they need sticks, we need to give them the sticks. If we don't give them any sticks, we can't complain that that don't have them and that they don't use them.</div><div dir="ltr"><br></div><div>As I said this by itself doesn't solve the problem, MANRS and other efforts are equally if not more important for the practical solution of this problem. But, If you think the RIRs should have any sticks at all to bring to bear even in the most systematic and egregious instances then we have to give them the sticks and that is done through T&Cs in the RSA contract. </div><div><br></div><div>If you don't think ARIN or the other RIRs should have any sticks, I can respect that, but then don't say "ARIN needs to grow a bigger stick."</div><div><br></div><div>Thanks.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 5, 2019 at 3:06 PM Adam Thompson <<a href="mailto:athompso@athompso.net">athompso@athompso.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I would suggest that ARIN needs to grow a bigger stick before there is any _point_ in changing the RSA to include specific language like that, anyway.<br><br>So ARIN terminates my contract and nullifies my number assignments - if I'm a malicious or even just egregiously negligent user, my reaction is "so what?" Even here in Winnipeg, there's at least one ISP I'm pretty sure will peer with me and/or advertise for me, even if I'm using bogus IP and AS numbers (for a suitable price, of course).<br><br>If MANRS/RPKI/IRR/etc. had decent adoption here, I think the situation would be different.<br><br>I just don't understand why we're talking about adding T&C's when there's so little consequence to willfully breaching them anyway.<br><br>-Adam<br><br><br><div class="gmail_quote">On August 5, 2019 12:42:13 p.m. CDT, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div dir="ltr">While I generally support the idea behind this change, the specifics of the language added to the RSA matters significantly. Furthermore, I do not believe that the language added to the RSA should be specific to routing. The language added to the RSA should be more generic, such as a commitment to not deliberately interfere with another registrant's use of the resources that are registered to them within the context of their use on Internet and not limited to any specific form of interference. Where making route announcements for blocks without permission of the registrant should be a specific example of such prohibited interference. </div><div dir="ltr"><br></div><div dir="ltr">Also, ARIN will need to create formal procedures, in addition to the informal procedures discussed in the following;</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/" target="_blank">https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/</a> </div><div dir="ltr"><br></div><div dir="ltr">I think only the registrant affected should be able to formally make a complaint and such a complaint is only actionable by ARIN after the accused is given a formal opportunity to cure the complaint.</div><div dir="ltr"><br></div><div>I think this type of change to the RSA is important and within the scope of the industry self-regulatory framework that the RIR system is intended to provide. Further, such a change promotes an equitable registry system, entities that are unwilling to respect other's registrations do not deserve the protections afforded to them by the registry system. For the RIR system to be taken seriously and provide effective industry self-regulation it needs a mechanism to sanction those that systematically and egregiously thwart the fundamental intent of the registry system, especially when such activities constitute deliberate interference with the proper operation of the Internet. <br><br></div><div>That said, while in my opinion, this change is necessary, it is only a very small part of the overall fix for the problem, as most incidents are neither systematic or egregious, and are usually not deliberate, most incidences are merely accidental. In addition this change to the RSA, the industry needs to adopt best practices for routing security, including route filtering and RPKI, to prevent and mitigate these accidental incidents, such as promoted by the MANRS program;</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://www.manrs.org/" target="_blank">https://www.manrs.org/</a><br></div><div><br></div><div>Thanks. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2019 at 2:24 PM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 31 July, we received a new suggestion, numbered 2019.17 upon confirmed<br>
receipt, that ARIN update its Registration Services Agreement. Staff is<br>
reviewing this suggestion and will issue a formal response once analysis <br>
is complete.<br>
<br>
The full text of the suggestion may be found below or at:<br>
<br>
<a href="https://www.arin.net/participate/community/acsp/suggestions/2019-17/" rel="noreferrer" target="_blank">https://www.arin.net/participate/community/acsp/suggestions/2019-17/</a><br>
<br>
***<br>
<br>
Description: ARIN should modify its Registration Services Agreement so <br>
that address holders agree to only announce routing for its own address <br>
blocks, or those address blocks for which it has obtained permission of <br>
the registrant as listed in the Internet Number Registry System.<br>
<br>
Value to Community: The additional value to the community would be that <br>
ARIN address holders would be far less likely to hijack routes as it <br>
would represent a breach of their agreement with ARIN.<br>
<br>
Timeframe: Not specified<br>
<br>
***<br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
_______________________________________________<br>
arin-suggestions mailing list<br>
<a href="mailto:arin-suggestions@arin.net" target="_blank">arin-suggestions@arin.net</a><br>
<a href="https://lists.arin.net/mailman/listinfo/arin-suggestions" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-suggestions</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_6575853663570814789m_-5200970538260029595m_-7240009749905681881m_1766390749043026100m_-864264758959371257m_-222091773504166411gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>