*pounds head on table* I'm really not sure how things get worse each
time but they appear to.
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.
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)
I'm done here. No more responses, no more arguments, no more
interaction. Do what you will. I'll just send out my "-1" and be done
with it.
Mike
On 2/1/2018 1:30 PM, Wes Hardaker wrote:
Sorry for the long delay to get this version out (vacation, family
issues, deadlines are all just excuses).
The -11 version of the document has a redesigned 6.1.6 that I'd love
everyone to concentrate on. Hopefully it more clearly articulates the
issues surrounding Mike's found need to wait yet another activeRefresh
and spells out the analysis behind the delay better (three potential
delays, from which we take the maximum value).
We had spoken at the last meeting of doing another update and a 1 week
last call again. Due to the complexity of the changes in -11, I'd like
to request a 2-week last call instead as I think the changes are
important enough to warrant a longer LC. Chairs? Thoughts?
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
