Dear Working Group, I want to discuss a proposal to change the format of the "members" field of the AS-SET and Route-Set objects in the RIPE DB. I do not know what the process is for this so please guide me if this is the wrong place or method for raising this kind of proposal. Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set object. Currently my AS-SET might look like the following when the tree is fully expanded: as-set: AS4200000011:AS-EXAMPLE-11 -> members: AS4200000011 -> members: AS4200000012:AS-EXAMPLE-12 - -> members: AS4200000012 - -> members: AS4200000021 -> members: AS4200000013:AS-EXAMPLE-13 - -> members: AS4200000013 - -> members: AS4200000022:AS-EXAMPLE-22 - - -> members: AS4200000031 When a peer or upstream is building a prefix lists towards me (AS4200000011), they need to generate a prefix list for my entire AS tree/route set tree. Historically, objects (AS-Sets/Roue-Sets) with the same name have been registered in different IRR databases. This causes a problem because it's not clear which IRR DB the object should be pulled from. When building a prefix list for a tree, some of the object are pulled from the wrong IRR DB. For example, AS-GOOGLE currently exists in the RIPE and APNIC IRR DBs, but the AS-SET in both DBs is empty: $whois -h whois.ripe.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE $whois -h whois.apnic.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE As per Google's peeringdb page, the correct data source for their AS-SET is RADB: https://www.peeringdb.com/net/433 $whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE members: AS11344 members: AS13949 members: AS15169 ... The above query to RADB produces the correct information. However, often when building a prefix set to a peer, the wrong object is used and an empty prefix list is generated, or the wrong prefix list, and the AS-SET may contain other false members too. Historically people have registered objects with the same AS-SET or Route-Set name in different IRR DBs, both by accident and maliciously, and this practice continues today. It is very difficult to get these issues resolved in a timely manner and the result on daily operations is that operators can't establish a new peering session with a customer/peer/upstream, or update a prefix list facing an existing customer/peer/upstream, because we can't generate the prefix list. We need to be able to signal which IRR DB is authoritative for an AS-SET or Route-Set object. For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers), and in their AS-SET's they can specify the correct source for each of their customers, and so on, all the way down the tree, so that I end up with my AS-SET tree looking like the following when fully expanded: -> members: RIPE::AS4200000011 -> members: RADB::AS4200000012:AS-EXAMPLE-12 - -> members: RIPE::AS4200000012 - -> members: ARIN::AS4200000021 -> members: ARIN::AS4200000013:AS-EXAMPLE-13 - -> members: APNIC::AS4200000013 - -> members: ARIN::AS4200000022:AS-EXAMPLE-22 - - -> members: RADB::AS4200000031 Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello@inter.link, Phone: +49-030-577123821 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss