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
