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

Alissa Cooper <alissa@cooperw.in> Wed, 04 December 2019 16:58 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC4D12085C; Wed, 4 Dec 2019 08:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JWKIJzCg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I+4jgae/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ri8C0D9AzU0; Wed, 4 Dec 2019 08:58:29 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB8712085E; Wed, 4 Dec 2019 08:49:19 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 417F8225BD; Wed, 4 Dec 2019 11:49:18 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 04 Dec 2019 11:49:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; 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= messagingengine.com; 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 (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (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 <alissa@cooperw.in>
In-Reply-To: <CA+9_gVvG-5Y5eqnx=yKULr_gCXXzsdgZb4pHvuba5GYtae-ZXQ@mail.gmail.com>
Date: Wed, 4 Dec 2019 11:49:16 -0500
Cc: General Area Review Team <gen-art@ietf.org>, IETF DNSOP WG <dnsop@ietf.org>, draft-ietf-dnsop-serve-stale.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFA9ECF8-80D0-4E09-B061-CAD784A40A50@cooperw.in>
References: <156868709386.28247.6521607966073267680@ietfa.amsl.com> <CA+9_gVvG-5Y5eqnx=yKULr_gCXXzsdgZb4pHvuba5GYtae-ZXQ@mail.gmail.com>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>, Brian Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/YfnJAqRYRx5G2y7SPYRUVKVeSF8>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dnsop-serve-stale-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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.

Alissa


> On Sep 18, 2019, at 12:20 PM, Puneet Sood <puneets=40google.com@dmarc.ietf.org>; 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
> <noreply@ietf.org>; 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>> 
>> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art