Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

[Wes Hardaker <[e-mail]>]

Michael StJohns <[e-mail]> 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