<div dir="ltr">Hi Mike, everyone,<div><br></div><div>In my opinion, opt-in is functionally equivalent to not changing anything at <br>all, because 95% of organizations will never make the conscious effort to click <br>the button. Some won't because of fear or ignorance of what it does, or because <br>they don't want to change the status-quo. Far more organizations won't simply <br>because they have no idea the button exists or because they aren't proactively <br>managed, and popup banners in the web UI or emails to mailing lists aren't <br>going to significantly change that. <br><br>While I'm a fan of Miles' suggestion to highlight discrepancies when editing <br>IRR/RPKI entries, particularly when it prompts people to implement/create RPKI <br>ROAs where they haven't done so already, I don't think it does much to mitigate <br>the problem we're looking at here. If the goal of this project is to harmonize <br>IRR data with RPKI data, then I believe that opt-out is the bare minimum <br>functionality to achieve that with any meaningful significance. <br><br>I was originally in favor of the opt-out mechanism, but upon further <br>contemplation, hearing Job's feedback, and seeing LACNIC's success with a <br>tightly-coupled integration, I am reasonably convinced as to the validity and <br>efficacy of that solution, and I agree that opening the door to discrepancies <br>WILL cause discrepancies (and outright issues as a result) to occur. I believe <br>that pure opt-in/opt-out exacerbates the long-tail problem as well. <br><br>However, given that the addition of this data to the IRR is conceptually <br>benign, as Job stated earlier, then I suppose the question/proposal I have is <br>this: Is it reasonable to tightly couple the creation of IRR route objects, but <br>have the _deletion_ of those route objects be optional? <br><br>There's no situation that I can think of where you would want an ROA without <br>the corresponding route object, and having that additional route object doesn't <br>cause any harm. If anyone has a counterexample where this behavior, and the <br>corresponding automatic "catch-up" mechanism, aren't purely beneficial, I'm all <br>ears.I think the tightly-coupled deletion of IRR route objects, however, is <br>what's causing some people concern. On ROA deletion, it may be preferable / <br>less objectionable to have a (default-on?) toggle for "Would you like to delete <br>this associated route object from the IRR database?". Again, this is on the <br>premise that having extra IRR data in the form of orphaned route objects is <br>benign, but that deleting IRR entries is _potentially_problematic for some </div><div>(though the only situation where I can see this being the case, is when </div><div>someone is attempting to cease using RPKI altogether, which is less-than-</div><div>ideal in and of itself!). <br><br>I'm still a fan of tightly-coupled automatic maintenance of IRR route objects <br>from RPKI ROAs, but perhaps the above is a reasonable middle ground </div><div>between opt-out and automatic maintenance.<br></div><div><br></div><div>Thanks for your consideration,</div><div><br></div><div>Rhys</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="arial, sans-serif"><b>Rhys Barrie</b> (He/Him)</font></div><div style="color:rgb(34,34,34)"><font face="arial, sans-serif">Senior Network Engineer</font></div><div style="color:rgb(34,34,34)"><font face="arial, sans-serif">Mott Community College</font></div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">Office <a href="tel:+1-810-762-0030" target="_blank">(810) 762-0030</a><br></div><div style="color:rgb(34,34,34)"><a href="mailto:rhys.barrie@mcc.edu" target="_blank">rhys.barrie@mcc.edu</a> | <a href="https://mcc.edu/" target="_blank">https://mcc.edu/</a></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 8, 2023 at 9:19 AM Michael Felden via ARIN-consult <<a href="mailto:arin-consult@arin.net" target="_blank">arin-consult@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">Hello everyone,<br>
<br>
Initially, I considered an opt-out option as a fine solution.<br>
<br>
This perspective was based on a 3 year old ASN with no technical debt and a straightforward network.<br>
<br>
Putting myself into the shoes of some of the other commenters here, their situation is *vastly* different from ours and it becomes clear why opt-in might be a more sensible approach.<br>
<br>
A possible compromise could involve implementing opt-in at the ORGid level, actively promoting it through the user interface and member communications, especially for new ORGs during on-boarding. <br>
<br>
This will leave 20 year old networks that have been through 5 rounds of M&A in peace. <br>
<br>
Additionally, we could explore implementing a feature suggested by Miles in a previous discussion:<br>
<br>
For ORGids that are not opted in who create an IRR object without a matching ROA, or vice versa, we could highlight this and provide a "sync this for me" button to create the corresponding object. Perhaps also display this delta when an org with existing objects opts in. Don't just create objects in the background but show them their status quo and have them confirm that they are happy with the before and after. <br>
<br>
<br>
Best, <br>
<br>
Mike Felden<br>
<br>
_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net" target="_blank">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-consult" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-consult</a> Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>