Hi Rob, wg, Sorry for the late reply.
For the record: I support adopting this work. I will reply to issues raised and discussed in this thread where appropriate. Here I just wanted to comment on this: > 2) We added a few timing parameters to the End Of Data PDU. These, > like the Serial Number mechanism, are lifted almost verbatim from > the DNS zone transfer protocol. We left them out of RFC 6810, but > subsequent exploration of some of the corner cases of the RPKI > Router protocol convinced us that leaving these timing parameters > out of the protocol had been a mistake. Can you elaborate a bit on why this had been a mistake? With regards to the minimum allowed value for the refresh. Why is it 120 seconds? That seems rather long to me. I understand that currently updates do not happen that often and propagate that quickly, but that may change. And if it does, and the RP tool sees more regular changes and it is confident that it can deal with load, then I think it would be better if it could use a lower number without having to revisit this text. With regards to the retry and expire intervals: I am not sure what I (as cache) should tell the router, so I would probably just go for the defaults. Reading them they look to me more like responsibilities of the client. But please let me know if I am missing something below.. Did you intend for the expire interval to be something that an operator can configure in the cache, and have it automatically propagated to the client routers? I think I would prefer to configure it on the routers. With regards to the retry interval, I am not sure if there should be any limit. Why can't the router decide, and what it is the synergy with having multiple cache configured in a router described in section 10? I think I may prefer to not limit the router's retries at all, and recommend operators to monitor their cache. Do we need a standard query type for the latter? At least to get the cache's own opinion on its health that could be integrated with monitoring? Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
