how would draft-ymbk-opsawg-finding-geofeeds work in noam

I have a question which might be about data flow here...

I assume that someone (entity) publishes a geo-feed <somewhere>
I assume that location of this feed (and others) is the goal of this work/draft.
   (I have no idea how this is done today.. aside from 1 implementation that
    requires a user to 'login' to a system and provide a url)

I don't see how you can easily link (correctly/securely) the publisher with
the correct data location, without something that clearly ties the
publisher to be the
owner/authorized-user of the ip space included in the geofeed.

To get to that tie, I'd just expect to see this published in RPKI.
Does that work for all/most cases? I think we heard terry manderson's proposal
in SIDR 'a long time ago' and 'everyone' said: "but what about the privacy!!!"
(we could have / did overreact maybe) but that use of rpki for
geo-feed-URL seems
like the simple way to tie owner/publisher.

$ubject changed as it is now where to put the pointer

[ we have email suggesting putting the geoloc pointer in dns, routing
  databases, ... no one has suggested bgp yet, but i assume it is
  coming ]

I assume that someone (entity) publishes a geo-feed <somewhere>
I assume that location of this feed (and others) is the goal of this work/draft.

yep

I don't see how you can easily link (correctly/securely) the publisher
with the correct data location, without something that clearly ties
the publisher to be the owner/authorized-user of the ip space included
in the geofeed.

the draft discusses that, see sec 4 and the sec cons

use of rpki for geo-feed-URL seems like the simple way to tie
owner/publisher.

i suspect 'simple' is not the term you want. perhaps 'authoritative'

folk want to publish usefully now, and in fact are doing so. this
scheme, admittedly a compromise, allows immediate incremental deployment
with optional authentication using the rpki; the best of both worlds.

also trying to minimize the silo bridging problem in large orgs