<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Dear Ben,<div><br></div><div>Thank you for bringing this to our attention.</div><div><br></div><div>We are currently investigating why this behaviour is happening.</div><div><br></div><div>The opaque-id description states that the opaque-id should reflect the same resource holder, thus this behaviour seems to be a bug so we will look into fixing it ASAP:</div><div><br></div><div><div><i>"Where opaque-id is introduced as an in-series identifier which uniquely identifies a single organisation, an Internet number resource holder.</i></div><div><i><br></i></div><div><i>All records in the file with the same opaque-id are registered to the same resource holder.</i></div><div><i><br></i></div><div><i>The opaque-id is not guaranteed to be constant between versions of the file.”</i></div></div><div><br></div><div><div style="display: block;"><div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt"><a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:228px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt" dir="ltr" role="button" draggable="false" width="228"><table style="table-layout:fixed;border-collapse:collapse;width:228px;background-color:#E5E6E9;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="228"><tbody><tr><td vertical-align="center" align="center"><img style="width:228px;filter:brightness(0.97);height:228px;" width="228" height="228" draggable="false" class="lp-rich-link-mediaImage" alt="preview.png" src="cid:B84C99D5-3F3C-4C97-9AE8-9FCB29E70FF9"></td></tr><tr><td vertical-align="center"><table bgcolor="#E5E6E9" cellpadding="0" cellspacing="0" width="228" style="font-family:-apple-system, Helvetica, Arial, sans-serif;table-layout:fixed;background-color:rgba(229, 230, 233, 1);" class="lp-rich-link-captionBar"><tbody><tr><td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem"><div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack"><div style="word-wrap:break-word;font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-topCaption-leading"><a rel="nofollow" href="https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt" style="text-decoration: none" draggable="false"><font color="#272727" style="color: rgba(0, 0, 0, 0.847059);">RIR-Statistics-Exchange-Format</font></a></div><div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading"><a rel="nofollow" href="https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt" style="text-decoration: none" draggable="false"><font color="#808080" style="color: rgba(0, 0, 0, 0.498039);">Text Document · 16 KB</font></a></div></div></td></tr></tbody></table></td></tr></tbody></table></a></div></div></div><div><br></div><div>Please feel free to contact us if you have any questions or concerns.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Petrit Hasani</div><div>RIPE NCC</div><div><div><br><blockquote type="cite"><div>On 27 May 2023, at 21:08, Ben Cartwright-Cox via db-wg <db-wg@ripe.net> wrote:</div><br class="Apple-interchange-newline"><div><div>I'm not 100% sure if this is the correct place to report/discuss this<br>quirk I've come across, but db-wg is the closest I have, so here it<br>goes.<br><br>In (what I call) the RIPE delegate file<br>https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest<br>Sponsored ASNs have slightly funny behaviour.<br><br>For ASNs that are sponsored, the account owner UUID is always the ASN<br>that sponsored the ASN first. If sponsorship is moved, the account<br>owner UUID does not change.<br><br>However given (as far as I understand) sponsored ASNs are PI<br>resources, surely they should get the same treatment as the IPv4 and<br>IPv6 entries (in that the PI holder has their own accountowner uuid)<br><br>What do we think?<br><br>Is this behaviour of being sticky to the original sponsor account UUID a bug?<br><br>Should sponsored ASNs have their own account UUID?<br><br>Have I completely misunderstood what any of this file means?<br><br>I ask most of this because my own system bgp.tools allows you to<br>quickly lookup resources by account, and for my own production ASN:<br><br>$ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest<br>| grep 206924<br>ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6<br><br>It shows all of the remaining ASNs that were originally registered by<br>the now defunct LIR:<br>https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6<br><br>Cheers<br>Ben Cartwright-Cox<br><br>-- <br><br>To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/<br></div></div></blockquote></div><br></div></body></html>