On 02/17/2017 12:21 AM, Wes Hardaker wrote: > Wes Hardaker <wjh...@hardakers.net> writes: > >> Fortunately, after a quick conversation we've recovered the reason. >> Publishing a new version with a break-out explanation shortly. The 3/2 >> is absolutely is needed. > > I've published -03 which adds new text just below the equation > explaining the components (and the equation got more complex to match > the complexity of 5011).
Thanks! The equation seems more complex at first glance but it is way more understandable for me. When reading the quote from the RFC5011 "Active Refresh" requirements, I realized the equation is not complete without: MAX(MIN(...), 1 hour) I.e. the waitTime would be too short for quick turn-around zones. This is probably not that important for practical deployment but it gets veeery important when transforming RFC text to a compliance test. Please add the MAX(), it will help someone in future. (I'm just trying to write compliance test for RFC 6672 ...) > Anyway, please do let me know if you think the new text adequately > explains the problem to you. The explanation seems good to me. Just a few comments about the text: It would be easier to understand for me if this paragraph was split into two (1st the constraint + 2nd prelude for analysis): /the matter/ The important timing constraint that must be considered is the last point at which a validating resolver may have received a replayed the original DNSKEY set (K_old) without the new key. It's the next query of the RFC5011 validator that the assured K_new will be seen. /prelude for analysis/ For the following paragraph, we use the more common case where (DNSKEY RRSIG Signature Validity) is greater than (original TTL for the DNSKEY RRSet), although the equation above takes both cases into account. Moreover the /prelude for analysis/ seems little bit confusing. What about something along these lines? /replacement prelude for analysis, preferably as separate paragraph/ The interval used by RFC5011 resolver is determined by lesser of (DNSKEY RRSIG Signature Validity) or (original TTL for the DNSKEY RRSet). Following text assumes that (DNSKEY RRSIG Signature Validity) is smaller of the two. /original text continues here/ Thus, ... > I probably need to go back and insert the > "worst case" timing into the example timeline, but that would make the > example a bit more messy. It seems sufficient to me to keep the analysis in (current) section 6. Maybe just a forwad-reference would suffice. Thank you for the clarification! -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
