<div dir="ltr"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 7:36 PM Owen DeLong via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@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"><div>The data is largely missing.<div>What’s not missing is largely inaccurate.</div><div><br></div><div>If anyone is relying on it for any purpose, that’s bad.</div><div>If we take away the bad data, then we can be sure that nobody is relying upon it. That’s good.</div><div><br></div><div>What am I missing?</div><div><br></div><div>Owen</div></div></blockquote><div><br></div><div>Additionally, as said in the problem statement of ARIN-2021-8 the ORIGIN-AS field it is difficult to consume; there are better options now, ARIN's authenticated IRR and RPKI. Furthermore, the field is not well-formed from a data typing perspective; it's just a text field. Additionally, when you have multiple sources of data, it is easy for those data sources to have different and conflicting data. I believe long term the best thing to do is to eliminate the ORIGIN-AS field in favor of the more well-formed and authoritative data in ARIN’s authenticated IRR and in RPKI. Also, at the ARIN 50 microphone, Rob Seastrom mentioned the policy that created this field and Sandra Murphy's original slides; here are links to them;</div><div><br></div><div><a href="https://www.arin.net/vault/policy/proposals/2006_3.html">https://www.arin.net/vault/policy/proposals/2006_3.html</a></div><div><a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_XVII/PDF/tuesday/2006-3-murphy.pdf">https://www.arin.net/vault/participate/meetings/reports/ARIN_XVII/PDF/tuesday/2006-3-murphy.pdf</a></div><div><a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_XVIII/PDF/wednesday/2006-3_Murphy.pdf">https://www.arin.net/vault/participate/meetings/reports/ARIN_XVIII/PDF/wednesday/2006-3_Murphy.pdf</a><br></div><div><br></div>The only question in my mind has been, what is the right timetable for deprecating the ORIGIN-AS field? Currently, some legacy resource holders don’t have access to ARIN’s authenticated IRR or to RPKI and only can use the ORIGIN-AS field. However, with the recent changes to the RSA/LRSA and the deadline to take advantage of the legacy fee cap, legacy resource holders should be properly incentivized to sign an LRSA and resolve this contracting issue well within the current timetable for implementation of this policy. See the following ARIN Announcements;</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://www.arin.net/announcements/20220912/">https://www.arin.net/announcements/20220912/</a><br></div><div class="gmail_quote"><a href="https://www.arin.net/announcements/20220913/">https://www.arin.net/announcements/20220913/</a><br></div><div><br></div><div>I support this Recommended Draft Policy as written.</div><div> </div><div>Thanks</div>-- <br><div dir="ltr">===============================================<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>