Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-serve-stale-07

Alissa Cooper <> Wed, 04 December 2019 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FC4D12085C; Wed, 4 Dec 2019 08:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.073, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=JWKIJzCg; dkim=pass (2048-bit key) header.b=I+4jgae/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ri8C0D9AzU0; Wed, 4 Dec 2019 08:58:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BB8712085E; Wed, 4 Dec 2019 08:49:19 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 417F8225BD; Wed, 4 Dec 2019 11:49:18 -0500 (EST)
Received: from mailfrontend2 ([]) by compute7.internal (MEProxy); Wed, 04 Dec 2019 11:49:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=c +CTrVM4u1bRWwrj6E2VllVVs8lz6NTb4o06peM+nzE=; b=JWKIJzCggwu0rpHcS npgUKdEBkjR8Pd78mYiJqKSjL2rbwjIycauIFfV+MRNHh7qzAtxtBwtTbXTy4DPQ kQOo76RhIgCTLU2jQlAROmt4dEb9AN5L4USICtYDwmVG58cZhYlOB1FEj57QGX9t OZzeKeiTFyc6SXaSvvQuMfnIysDU2Q6WP3uwYitKS9gbrz3DgWsI68NgdY+1Fdjh UeImMaaQFcVxmz8oCcwTyXvfdV3iLHfoSTWgfnqvK7zkrTlK2JXIpzKTpG+aoqJ1 gz2zYInsFWZ76hgMEYBEf2dpUa3eFE/Mom6+PSXZCyK8kOk0kmKKdlp1RUYcx+B/ 6ZIQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=c+CTrVM4u1bRWwrj6E2VllVVs8lz6NTb4o06peM+n zE=; b=I+4jgae/qMK4I4yGfmvpN8MheNmyfNQFT31uhtP4q5Klv0XZuEk9K4R3d WE7gVOSUQleVPmKcdHXEhjido22hCiTcLFLGLJglw2U87PaQF6iWrhfFFOxGeA19 HIkPcguBW8m3py65HJUpSHMPbSuN2lXWnV4CgSLuopdFxEyi8vpEkjUnVdBRj53j 8wKMKEBPZvO2pb/hsIpgMzZmfFS/0UWCoESyJ5X35ZvlyLXujuJZq/OljWKqRdlX dVv2+d6EKKU8qLieB0Yx7Aazxawt96WGOhnC4T0gKpcF9y7B5pYuuN0fzuGZaFmG C+fus4QQRnlMJWUCGPrB/YrJ5seog==
X-ME-Sender: <xms:jePnXdod6MXqZDD4h2HsG44QHx0X5jK0GJBTmpC2xWv9Z34nTvonGg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejledgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtuddrleeknecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:jePnXT6HwwC7zOwJGsGkZ_QvAloHApJ0upbNN9iKh--lJsucB_3FfQ> <xmx:jePnXVM2lTEKYGnb54Wmh_0o9OoiKBXwi8k-V1Q6zaypj4JCFu8puA> <xmx:jePnXdO82UjKvpTu2dEpAifbHpTNo4m01yAni-hDyJ53JzUJKXxm0Q> <xmx:juPnXTJeVFXkoKoqPUs4HxcUaPuf0A02Ldw0ooq_p9iSrNdROQyHjA>
Received: from alcoop-m-c46z.fios-router.home ( []) by (Postfix) with ESMTPA id AA04430600A8; Wed, 4 Dec 2019 11:49:17 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 4 Dec 2019 11:49:16 -0500
Cc: General Area Review Team <>, IETF DNSOP WG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Puneet Sood <>, Brian Carpenter <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-serve-stale-07
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: Wed, 04 Dec 2019 16:58:30 -0000

Brian, thanks for your review. Puneet, thanks for your response and for updating the draft accordingly. I entered a No Objection ballot.


> On Sep 18, 2019, at 12:20 PM, Puneet Sood <> wrote:
> NOTE: Responding to the TTL concerns raised in multiple threads
> (thanks Viktor Dukhovni, Tony Finch) here since it seems to cover all
> the lists.
> On Mon, Sep 16, 2019 at 10:24 PM Brian Carpenter via Datatracker
> <> wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>> Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-ietf-dnsop-serve-stale-07.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2019-09-17
>> IETF LC End Date: 2019-09-25
>> IESG Telechat date:
>> Summary: Ready with issue
>> --------
>> Major issues:
>> -------------
>> "(It [RFC2181] also has the curious suggestion that a value in the
>> range 2147483648 to 4294967295 should be treated as zero.)"
>> I don't see why that is "curious". That is the range of unsigned
>> 32-bit integers that would be negative if treated as signed 32-bit
>> integers. And in any case, the statement seems unfair to the authors
>> of RFC2181, which actually says this:
>> "It is
>> hereby specified that a TTL value is an unsigned number, with a
>> minimum value of 0, and a maximum value of 2147483647... this value
>> shall be encoded in the less significant 31 bits..."
>> It's not a "suggestion"; since the RFC does not use RFC2119 keywords,
>> it's a requirement. It's unambiguous, and obviously motivated by
>> resilience to coding errors around signed vs unsigned integers. That
>> was a legitimate concern in 1997. As best as I can tell, in 1997
>> standard C did not include uint32; you needed to use unsigned long int
>> and hope it was mapped to 32 bits.
>> So the current draft overrides this choice made in RFC2181. Since that
>> choice had an obvious (but unstated) motivation, how do we know that
>> allowing TTLs above 2147483647 will not trigger long-standing coding
>> bugs?
>> There's an alarm bell later in the draft:
>> "Regarding the TTL to set on stale records in the response,
>> historically TTLs of zero seconds have been problematic for some
>> implementations, and negative values can't effectively be
>> communicated to existing software."
>> You bet. If the TTL is specified as an unsigned 32 bit integer, and
>> stored in a uint32, negative values are impossible. But if the coding
>> is sloppy and used long int, "if ttl > 0" could go horribly wrong.
>> Maybe it's all OK and there is no old resolver code out there with coding
>> errors for values above 2147483647. Did the WG discuss this? I think the
>> "curious suggestion" text above should be replaced by a brief discussion
>> of why RFC2181 made the change that it did, and why it's now safe to
>> reverse it.
> The primary concern is around treating TTL values with the high bit
> set as positive numbers resulting in really long TTL value either
> intentionally (someone added that to a zone configuration) or
> unintentionally (e.g. software incorrectly decrementing a zero value
> or small positive value). The responses from Tony and Brian clarify
> why the wording in RFC 2181 is written the way it is. My co-authors
> have more context on the changes for TTL interpretation. I will follow
> up and we will come back with a response.
> I will also address the editorial comments around the TTL text with tat.
> Thanks,
> Puneet
> _______________________________________________
> Gen-art mailing list