> I just reviewed rev -02. Other than noticing two ’s’ in “objects”
> in section 5, I didn’t notice any other issues.
thanks for taking a pass. objectss corrected, plus a other thinks
erik kline pointed out. we'll push -03 when there have been changes
of substance.
> 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?
i have recently become overly sensitive to this. i have turned off
rrdp on my rpki CAs because of a DDoS by abusive pollers. and i may
be driven to just turn off rpki entirely.
i see at least three pieces to the problem
o what is a reasonable frequency? imiho, things change very
infrequently. the ietf meeting network should be happy with a
weekly poll. but, as ggm might say, there is a discussion to be
had here.
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.
o given the rpki DDoS, will implementors even follow guidelines in
an RFC? if we assume not, then we probably should also specify
a damping mechanism on the service side. there is a reason rpsl
servers are strongly damped. welcome to the tragedy of the
commons.
folk might have other thoughts.
again, thanks for reading!
randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
