On Sep 14, 2020, at 01:11, Erik Kline <ek.i...@gmail.com<mailto:ek.i...@gmail.com>> wrote:
On Sun, Sep 13, 2020 at 11:10 AM Massimo Candela <mass...@us.ntt.net<mailto:mass...@us.ntt.net>> 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. Thanks, Erik. Yes, that should cover the periodicity. A reference to that might be a good addition to the ops considerations in your new draft to complement the bit about not polling in real-time. Joe
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
