Michael StJohns <m...@nthpermutation.com> writes: > Please, please get rid of activeRefreshOffset, clockskewDriftMargin > and retryDriftMargin. Replace this with a single paragraph noting > that the maximum time (assuming no retransmissions) a node has to wait > after its holdDownTime expires is activeRefresh. (e.g. the conclusion > you reach at the bottom of 6.1.6). The rest of the math you have is > basically explaining why in certain chosen circumstances some nodes > might get there early.... and that's a don't care when looking at > worst case.
Thanks for the review Mike. 6.1.6 gets to the value you want (activeRefresh), by more explanation than you want because I'm doing showing a full analysis of all issues. I think we'll need to agree to disagree on whether the full analysis is beneficial to the document or not (I believe it is). > 6.2.1 and its related wall clock calculation should be only > > > addWaitTime = sigExpirationTime + // this is the last time that an > old signature can be replayed > activeRefresh + // this is the latest time > that a node can start its addHoldDown timer (assuming no > drop/retransmit/fail) > addHoldDownTim + // this is the latest > time that a node can finish its addHoldDown interval (assuming ") > activeRefresh + // this is the latest time > that a node can install the new trust anchor (assuming ") > retrySafetyMargin // this is the > additional time the publisher should wait to compensate for real-world > issues (drops/retransmits/networkfailure) That's what's in 6.2.2, so we're good there. I realize you don't like the flipside in 6.2.1, but again that's where we disagreed on the best way to present it so I added both so we'd both be happy. In the end, in this version of the document you and I both agree on the math, but not necessarily on how it's presented. Thanks. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
