When an RIR asserts geo in Whois, it's derived from the organisational data, but usually/often then self asserted. It was asserted by the delegate, during registration. When an RIR asserts geo in organisational data, it's self-asserted through a filter of things like Dunn & Bradstreet and company registration numbers. Its less subject to change by the delegate, because its about them, maintained by the registry. It's as subject to risks of being wrong, as anything else about an entity. What gets published by an RIR in things like delegated stats is from organisational status, not geolocation of the IP addresses in most cases. So its the "about them, maintained by registry" data There isn't a strict formalism about how this data is verified. There isn't some magic geo verification service, which would inherently vest the data with more than the value of self assertion. It varies by economy, and compliance issues. For some economies, the data is really high value. For others, its moot. I think the RFC geo mechanism, is inherently as good as self-asserted data in Whois or RDAP. I think its probable it has more specificity for prefixes used outside the economy of registration of the entity which is delegated: and that's increasingly common. I think, its a better mechanism overall. The disconnect between what is registered, what is (self) declared, what is aggregated by geo-IP intelligence companies, what is learned by BGP speakers, what is actually used, is huge. I think we're doing ourselves a misservice by allowing this to be ill defined, but I would be wary of declarations source A is inherently better than source B. A lot of it, I think is about the curation. If it's well curated, a good sign is responsiveness to reports it's wrong about some prefix. Having said that, the interface inside large entities can be very opaque. I think this is another disconnect: Between engineers who specify things like geolocation format in IETF, and service delivery people who may have other goals. cheers -G