yang,
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.
Then there is no more need to host HTTP server. 1 HTTP request per inetnum/inetnum6 object seems a bit tedious.
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?
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. 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? note that use of the remarks: attribute is for rpsl services which do not implement the specific geofeed: attribute. [ e.g. see the PR for IIRDv4 https://github.com/irrdnet/irrd/issues/396 ]
Specific to the north american RIR, NetHandle is in registry (not in irr) abd bulk access requires application (https://www.arin.net/reference/research/bulkwhois/#accessing-bulk-whois-data), download requires cookies and takes ~10 mins. imo this could be made easier like https://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz
there are a lot of things arin could make life more easy for operators. and cash could fall from the sky.
NetHandle is not exactly inetnum (e.g. comments instead of remarks field, different prefix format). Would the RIR provide converted inetnum objects or the users would be expected to handle this?
i currently fear a custom stub to do just this for consumers of north american data. randy