Michael StJohns <[email protected]> writes: > A "perfect" system will behave the way you've described - but adding a > safety factor while ignoring the phase shift brought on by retransmits > within the addHoldDown interval will not characterize the actual > system.
Ah ha! So, you do actually agree that my description of the perfect case is true, which means we really have been in violent agreement about the "perfect" line in the sand. [as I've said: I absolutely understand the point your making about real world issues, such as timing drifts] And as I said in the last message, I agreed that a delay/phase-shift made sense and I'd be happy to produce a new term for it. Ideally I'd like to add that into the safetyMargin because it reflects real-world conditions, and I was trying to contain that to just one particular term. But I understand you don't want it buried in there, so I'll create a new term to deal with timing phase shifts and add that before the existing safetyMargin. > Can we stop now? I think so as I believe I can add words that we'll both agree to. But I've said that before, so... The only remaining questions, just to double double be sure: 1) "is one activeRefresh period long enough to account for the slop associated with time clock drifts?" I'd argue yes, as any clock that drifted longer than an activeRefresh (min = 1hr) is a seriously broken clock. I think you agree. 2) "is one activeRefresh period long enough to account for network delays and other elements, aside from 'retries and missing queries'?" I think you and I agree on this too, that one should be sufficient to cover network delays too. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
