Michael StJohns <m...@nthpermutation.com> writes: > Also, you're still missing the fact that a given resolver can start > its addHoldDown timer anywhere in the range of [0..activeRefresh] > AFTER the signature expiration depending on when it was starting its > clock. All of your calculations are starting from the wrong point.
No I'm not. Set the resolver query offset amount to something large and it does exactly what you're talking about. I didn't forget it. In fact, the most interesting case is when you set it large (set it to 300d, and the code will clip it to activeRefresh-1 anyway) and then you set the resolver query drift amount to -1. You'll note, in this case, that that the dnskey is accepted *after* my current activeRefreshOffset line, *proving* your case. You keep saying I don't understand and don't agree with you, but if this doesn't prove that I both do understand and agree with the problem I don't know what will. Go change *only* those two lines in the simulator and it *shows* that you have very legitimately found a source of real-world error that must be accounted for. > > Your calculations represent the best case [e.g. triggers at 0 for both ends > of the problem] when what > you want is worst case. Try 300d in resolver query offset. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
