> > 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
