<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 12:10 PM John Curran <<a href="mailto:jcurran@arin.net">jcurran@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"><br>
In effect:. “Address Holder agrees to only route to the Internet its own address blocks, or those address blocks for which it has obtained permission of the registrant as listed in the Internet Number Registry System.”<br>
<br>
Does the reformulation help clarify why the addition of that responsibility might be seen by some as rather significant?  If you actually intend it to be a meaningful change, then it should include the corresponding obligation in clear and uncertain terms.<br>
<br>
It’s possible that such a change is reasonable if the community wishes, but absent a clear and unified expression of support, ARIN could not consider adding such obligations to registry customers. <br></blockquote><div><br></div><div>John,</div><div><br></div><div>If the community wishes to move forward and add similar language as the above to the RSA, what is the best way to move forward? The ACSP? I assume the PDP is not as it is an RSA contract issue and not directly a policy issue.</div><div><br></div><div>Further, if similar language as the above was added to the RSA, then BGP hijacking effectively becomes a breach of RSA contract and ARIN could terminate the perpetrator's RSA for cause under section 13b of the RSA and effect a return of all resources if the breach remains uncured for more the 60 days.  How would a series of repeated non-continuous breach events, none of which exists for more than 60 days, be handled? Would 13b of the RSA need to be modified as well to handle this type of repeated but non-continuous breach? </div><div><br></div><div>In any case, the goal would be to cure the breach and bring the other party into compliance if at all possible, termination is not the primary goal, cure of the breach is the primary goal. Termination is the last resort and the result of an uncured breach.</div><div><br></div><div>I'll note that such a change in the RSA would create a strong operational incentive for publication of valid information, with at least some level of authentication, about the proper origination of prefixes, either through the use AS Origin in the Registry, the forthcoming updated ARIN IRR, or through RPKI ROAs. As these are easy ways for the proper resource registrant to express their intent for someone else to originate their prefixes.</div><div><br></div><div>Thanks</div></div><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></div></div></div>