Sponsored ASNs AccountOwner's in extended delegate file don't move with sponsor
I'm not 100% sure if this is the correct place to report/discuss this quirk I've come across, but db-wg is the closest I have, so here it goes. In (what I call) the RIPE delegate file https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest Sponsored ASNs have slightly funny behaviour. For ASNs that are sponsored, the account owner UUID is always the ASN that sponsored the ASN first. If sponsorship is moved, the account owner UUID does not change. However given (as far as I understand) sponsored ASNs are PI resources, surely they should get the same treatment as the IPv4 and IPv6 entries (in that the PI holder has their own accountowner uuid) What do we think? Is this behaviour of being sticky to the original sponsor account UUID a bug? Should sponsored ASNs have their own account UUID? Have I completely misunderstood what any of this file means? I ask most of this because my own system bgp.tools allows you to quickly lookup resources by account, and for my own production ASN: $ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest | grep 206924 ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6 It shows all of the remaining ASNs that were originally registered by the now defunct LIR: https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6 Cheers Ben Cartwright-Cox
Dear Ben, Thank you for bringing this to our attention. We are currently investigating why this behaviour is happening. 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: "Where opaque-id is introduced as an in-series identifier which uniquely identifies a single organisation, an Internet number resource holder. All records in the file with the same opaque-id are registered to the same resource holder. The opaque-id is not guaranteed to be constant between versions of the file.” https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt RIR-Statistics-Exchange-Format Text Document · 16 KB Please feel free to contact us if you have any questions or concerns. Kind regards, Petrit Hasani RIPE NCC
On 27 May 2023, at 21:08, Ben Cartwright-Cox via db-wg <db-wg@ripe.net> wrote:
I'm not 100% sure if this is the correct place to report/discuss this quirk I've come across, but db-wg is the closest I have, so here it goes.
In (what I call) the RIPE delegate file https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest Sponsored ASNs have slightly funny behaviour.
For ASNs that are sponsored, the account owner UUID is always the ASN that sponsored the ASN first. If sponsorship is moved, the account owner UUID does not change.
However given (as far as I understand) sponsored ASNs are PI resources, surely they should get the same treatment as the IPv4 and IPv6 entries (in that the PI holder has their own accountowner uuid)
What do we think?
Is this behaviour of being sticky to the original sponsor account UUID a bug?
Should sponsored ASNs have their own account UUID?
Have I completely misunderstood what any of this file means?
I ask most of this because my own system bgp.tools allows you to quickly lookup resources by account, and for my own production ASN:
$ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest | grep 206924 ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6
It shows all of the remaining ASNs that were originally registered by the now defunct LIR: https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6
Cheers Ben Cartwright-Cox
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Dear Ben, We have resolved the issue with inconsistent opaque-ids for ASNs belonging to the same resource holder in the extended delegated stats files. Thank you again for bringing this bug to our attention. Please feel free to contact us at sw-bugs@ripe.net <mailto:sw-bugs@ripe.net> for any similar concerns. Kinds regards, Petrit Hasani RIPE NCC
On 31 May 2023, at 13:54, Petrit Hasani via db-wg <db-wg@ripe.net> wrote:
Dear Ben,
Thank you for bringing this to our attention.
We are currently investigating why this behaviour is happening.
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:
"Where opaque-id is introduced as an in-series identifier which uniquely identifies a single organisation, an Internet number resource holder.
All records in the file with the same opaque-id are registered to the same resource holder.
The opaque-id is not guaranteed to be constant between versions of the file.”
https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt
Please feel free to contact us if you have any questions or concerns.
Kind regards,
Petrit Hasani RIPE NCC
On 27 May 2023, at 21:08, Ben Cartwright-Cox via db-wg <db-wg@ripe.net> wrote:
I'm not 100% sure if this is the correct place to report/discuss this quirk I've come across, but db-wg is the closest I have, so here it goes.
In (what I call) the RIPE delegate file https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest Sponsored ASNs have slightly funny behaviour.
For ASNs that are sponsored, the account owner UUID is always the ASN that sponsored the ASN first. If sponsorship is moved, the account owner UUID does not change.
However given (as far as I understand) sponsored ASNs are PI resources, surely they should get the same treatment as the IPv4 and IPv6 entries (in that the PI holder has their own accountowner uuid)
What do we think?
Is this behaviour of being sticky to the original sponsor account UUID a bug?
Should sponsored ASNs have their own account UUID?
Have I completely misunderstood what any of this file means?
I ask most of this because my own system bgp.tools allows you to quickly lookup resources by account, and for my own production ASN:
$ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest | grep 206924 ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6
It shows all of the remaining ASNs that were originally registered by the now defunct LIR: https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6
Cheers Ben Cartwright-Cox
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Wonderful, I just checked to confirm and it indeed does look correct. Thanks to all involved! On Thu, Jun 15, 2023 at 3:59 PM Petrit Hasani <phasani@ripe.net> wrote:
Dear Ben,
We have resolved the issue with inconsistent opaque-ids for ASNs belonging to the same resource holder in the extended delegated stats files.
Thank you again for bringing this bug to our attention.
Please feel free to contact us at sw-bugs@ripe.net for any similar concerns.
Kinds regards,
Petrit Hasani RIPE NCC
participants (2)
-
Ben Cartwright-Cox -
Petrit Hasani