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

[Randy Bush <randy () psg com>]

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