Re: [DNSOP] [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: dnsop@ietfa.amsl.com
Delivered-To: dnsop@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, 04 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/dnsop/rbHNpVclyKhcIIi4VBn57XXtmQ8>
Subject: Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-serve-stale-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-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
- [DNSOP] Genart last call review of draft-ietf-dns… Brian Carpenter via Datatracker
- Re: [DNSOP] Genart last call review of draft-ietf… Puneet Sood
- Re: [DNSOP] [Gen-art] Genart last call review of … Alissa Cooper