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

Dave Lawrence <> Thu, 24 October 2019 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84D33120047; Thu, 24 Oct 2019 12:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H98NrnRk05Iu; Thu, 24 Oct 2019 12:35:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D014120020; Thu, 24 Oct 2019 12:35:47 -0700 (PDT)
Received: by (Postfix, from userid 102) id 2657F99F31; Thu, 24 Oct 2019 15:35:46 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Thu, 24 Oct 2019 15:35:46 -0400
From: Dave Lawrence <>
In-Reply-To: <>
References: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 19:35:51 -0000 writes:
> A diff from the previous version is available at:

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.