On Sun, Sep 13, 2020 at 11:10 AM Massimo Candela <[email protected]> wrote:
> Hi Joe, > > Thanks for your feedback. > > > > >> One thing that did stick out to me, though (and I don’t know how to > >> solve it) is when you talk about update frequency in section 5. Okay, > >> don’t do frequent polls and don’t poll at midnight. However, in the > >> case of something like the IETF conference network, how would > >> consumers know that this GeoFeed data _is_ likely to change and at a > >> certain periodicity? The GeoFeed format doesn’t have any parsable way > >> to reflect that. I don’t know if RPSL does. Perhaps the remark: > >> could offer some clue as to when one might want to come and retaste? > > > > > > o could there be a signal on the server side, e.g. an expiry or > > suggested poll frequency in the geofeeds file or in the pointer in > > the rpsl? for example, massimo is looking at html tags. > > What I'm loking at is http cache max-age headers. > Since the geofeed file is served on http(s), that's free to achieve > (like for any other file). > FWIW, we tried to have some HTTP header discussion in 8805: https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information The IETF is an example that can be solved with a simple operational practice that Warren already implements: update the contents of the feed the day after the conference ends. This gives everyone ~3 months to learn the new location from the updated feed.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
