Hi Dave, Thanks. I think that covers it. I still suspect that the original reason was concern about int versus uint confusion, but the new text is fine.
Regards Brian Carpenter On 25-Oct-19 08:35, Dave Lawrence wrote: > internet-dra...@ietf.org writes: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09 > > This revision addressed the one remaining outstanding issue that Brian > Carpenter raised in the Gen-ART Last Call Review. The following text > was added to explain why a TTL with the high-order bit set is now > handles as a large positive number (then capped down) rather than a > negative number (and treated as zero). > > As for the change to treat a TTL with the high-order bit set as > positive and then clamping it, as opposed to [RFC2181] treating it as > zero, the rationale here is basically one of engineering simplicity > versus an inconsequential operational history. Negative TTLs had no > rational intentional meaning that wouldn't have been satisfied by just > sending 0 instead, and similarly there was realistically no practical > purpose for sending TTLs of 2^25 seconds (1 year) or more. There's > also no record of TTLs in the wild having the most significant bit set > in DNS-OARC's "Day in the Life" samples. With no apparent reason for > operators to use them intentionally, that leaves either errors or > non-standard experiments as explanations as to why such TTLs might be > encountered, with neither providing an obviously compelling reason as > to why having the leading bit set should be treated differently from > having any of the next eleven bits set and then capped per Section 4. > > I also removed the phrasing about 2181's handling of this issue as a > "curious suggestion". I recognize it could have an unintended > negative connotation against the original authors, though when I wrote > the sentence originally I meant it only with its neutral denotation. > It was curious to me only because no rationale was provided as to why > that particular choice had been made, despite the current assertion > that it was obvious as to why. > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
