Why not publish RFC8805 Geofeed directly in inetnum remarks section?
for some flat fan out last kilometer providers that could be the inetnum: object from hell. there are global providers which segment large prefixes over diverse areas. etc.
i doubt the rpsl providers would like multi-megabyte inetnum:s. rpsl providers already throttle in defense.
I was thinking about geofeed on customer assignment objects for networks that manage their own objects (https://www.afrinic.net/press/214-creating-customer-assignments), only 1 line of geofeed remark needed on each object (more objects should be created if used in different locations). But not all RIR have customer assignment objects (can't create sub-assignment objects on ARIN direct assignment resources). HTTP feed does make sense when customer assignment object is not an option.
we are not expecting these lookups to be done frequently. i agree that would hammer servers, both rpsl and geofeed. do you have stronger words to suggest than
5. Operational Considerations ... An entity fetching geofeed data through these mechanisms MUST NOT do frequent real-time look-ups to prevent load on RPSL servers. And do not fetch at midnight, because everyone else may.
i agree that we do not want the DDoS that is currently happening to RPKI publication servers. perhaps explicit time limits, e.g daily? I am more concerned about clients having to make large amount of HTTP requests if this field gets widely used, maybe some clients can just read input like RPKI VRP (https://rpki.cloudflare.com/rpki.json) Client can try to keep track of geofeed URLs and only download the file during iteration, despite the same file referenced by multiple objects.
How to handle other stuff that might exist in remarks field? Or the draft would explicitly require Geofeed to be in its own remarks field?
the document tries to be explicit that it is the latter. that is the intent of
3. inetnum: Class ... the syntax of a Geofeed remarks: attribute which contains a URL of a geofeed file. The format MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary. ---> probably add clarification here that Geofeed MUST be the only value in this particular remarks field, nothing before/after it
inetnum: 192.0.2.0/24 # example remarks: Geofeed https://example.com/geofeed.csv
Any particular inetnum: object MAY have, at most, one geofeed reference.
is there more specific wording that would help clarify?
see above Yang