<div dir="auto">Colleagues Any thoughts on these 'RIPE-NONAUTH' objects? On Tue, 22 Nov 2022 at 21:17, denis walker <<a href="mailto:ripedenis@gmail.com" target="_blank" rel="noreferrer">ripedenis@gmail.com</a>> wrote: > > Hi Nick > > On Tue, 22 Nov 2022 at 20:11, Nick Hilliard <<a href="mailto:nick@foobar.org" target="_blank" rel="noreferrer">nick@foobar.org</a>> wrote: > > > > denis walker via db-wg wrote on 22/11/2022 19:00: > > > Any thoughts on this? There are 2128 AUT-NUM objects with source > > > RIPE-NONAUTH. Do we want these to be able to authorise the creation of > > > hierarchical AS-SET objects when we don't know who maintains the > > > AUT-NUM objects? > > > > I don't see a particular reason to prevent holders of existing NON-AUTH > > ASNs from defining a hierarchical AS-SET object associated with their > > ASN. The as-set object would be no more or less authoritative than the > > aut-num object. > > Then another option could be to only allow such objects to also have > the source NONAUTH > > > These ASNs have 'source: RIPE-NONAUTH' because we don't know who created the AUT-NUM objects or who now maintains them in the RIPE Database. They were created when anyone could create an AUT-NUM object in the RIPE Database for non RIPE issued ASNs. Authorisation was bypassed to allow them to be created. The 'NONAUTH' tag makes it clear they are not authoritative. Consumers of this data can then make an informed decision about whether or not they trust these objects. If we allow these objects to authorise hierarchical AS-SET objects with 'source: RIPE' we have in effect turned non authoritative data back into authoritative data. If we give the related AS-SET objects 'source: RIPE-NONAUTH' we make it clear that these objects are also not authoritative. Consumers of the data should make their own informed decisions about the content of these AS-SET objects. cheers denis co-chair DB-WG </div>