On date time vs intervals - I finally realized why Wes and I are
somewhat disconnected on this.
5011 was written as the protocol for the resolver and is totally
interval driven. (E.g. query and retry timers are set and fire based
on when the resolver performs an action).
This document is being written for the zone publishers, and the process
of publication is task driven and has humans as protocol element
timers. The actual publication of a DNSSEC RRSIG is divorced from both
the date/time of creation and the RRSig's actual inception and
expiration dates. While there is a defined interval between inception
and expiration, expiration occurs at a fixed point in time and that
point in time is independent from the interval between publication and
receipt by the client.
In other words - the correct (or at least better and less subject to
being misunderstood) way of describing the various points in time the
publisher should do something is by referencing the fixed point in time
(expiration) where both publisher and client agree that something
happens and then figuring other fixed points in time from that point.
Or to restate it again - "A publisher must wait until June 5th 2010"
will always evaluate to the same date and time regardless of who
calculates it and when they calculate it; "A publisher must wait 30
days" will not.
So :
"
publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW DNSKEY
RRSet) + MAX ( all calculated queryIntervals for OLD and new RRSets) +
addSlopInterval
queryInterval ::= MAX (1 hour, MIN (
15 days,
.5 * expirationInterval
DNSKey RRSet,
.5 * originalTTL DNSKey
RRSet)
)
expirationInterval :: = expirationDate - inceptionDate
addSlopInterval ::= 2 * MAX(originalTTL of any DNSKEY RRSet valid
during the transition process)
The publicationAddWaitDateTime is the date and time on which the
publisher can assume that most of the 5011 capable resolvers have
accomplished the addition of the new trust anchor to their trust anchor
sets. That date is the addHoldDownTimeInterval AFTER the latest in time
signature expiration date of any RRSet without the new key. This
includes both published and unpublished RRSets. Publishers should
refrain from creating or publishing DNSKEY RRSets signed exclusively by
a new key until after this date. Specifically, the inception date of
such an RRSig should be later than the publicationAddWaitDateTime"
The addHoldDownTimeInterval above differs from what is in 5.1 section
2.4.1 in that this is the publishers view of when the new trust anchor
is accepted by the resolver which may differ from a specific resolvers
view (due to when things are actually sent and received). Section 2.4.1
has to be combined with the text in section 2.2 which states that the
key isn't added until after the next time it is seen after the
expiration of the add hold down. Also, the queryInterval term of this
calculation should be the maximum of any DNSKEY RRSet seen during the
transition - it's possible that the publisher may reduce the intervals
or increase the intervals between RRSets and this provides the publisher
with the worst case value that any given resolver should be using.
Let's not confuse resolver numbers with publisher numbers and spend a
bit of time to get the language clear correct and implementable.
Mike
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
