Hello db-wg, A simple query to the RIPEDB ('whois -h whois.ripe.net -r AS2856') returns the aut-num AS2856 that you would expect, but it also returns a mntner with the same primary key: % Information related to 'as2856' mntner: as2856 admin-c: JA6431-RIPE auth: SSO # Filtered mnt-by: as2856 created: 2018-08-23T15:46:37Z last-modified: 2018-08-23T15:46:37Z source: RIPE # Filtered This has caused some concern, and while we (2856) have already determined how that mnter came to be in the database - and that there isn't any immediate risk - it isn't in any way affiliated with the AS2856 network, or any part of the parent company. One can imagine that given the quality of NOCs & their understanding of database objects the world over, that one of them might be convinced that the person associated with this mntner was indeed associated with the network AS2856, and they might also be convinced to announce prefixes that they otherwise should not. It is obvious that speaking to the owner of the mntner and politely asking them to switch to a new mntner would be pertinent, but as far as I'm aware they're under no obligation to do so. Yet, it feels that AS2856 (or any network in the RIPE region) remains potentially at some risk should a bad actor combine such a mntner, with some questionable verification of their credentials, and socially engineer their way toward a route hijack. Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?) Might there be negative side-effects in restricting the primary key of mntners from impersonating other objects? I'm unable to construct a query to the RIPEDB that looks for mntner objects beginning with 'as', in order to gauge how common this is. I suspect that's because the phrase is too short, but if it is possible please do enlighten me! :) Regards, -- Tom