Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

[Dave Lawrence <[e-mail]>]

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