Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

Ted Lemon <> Thu, 21 February 2019 23:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F350E131294 for <>; Thu, 21 Feb 2019 15:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bR4zgfBbk03K for <>; Thu, 21 Feb 2019 15:29:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ADBD130ECE for <>; Thu, 21 Feb 2019 15:29:05 -0800 (PST)
Received: by with SMTP id i20so170530pfo.6 for <>; Thu, 21 Feb 2019 15:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FtEV5FAc4BfJQsqm1VvDTpjGsecEiJTSJzu6GUXAiOc=; b=HTJ8j3Pp0CNRKE/zPkOVDvc3dsfqWq3lAaulnsavz9ojx6sxSW7y7PalCYNz+GtNNa Xkh3ecB/6c8tINzgxLG4bU3L+xE1S1Iux5Z3nIzxRA4xrdpvRSGugU8rTQY+KOxd+RM6 AhQbLLSQDNmbMQ32zDZ7O777xmfPLA+D3Y0qMYDNL523rhR6oJzGGxqCkOdU5fb7JL8j 4N47L6xZcGUIaA/4QuHrX3kOFF+whiqigOFwgK/DyAFOWqE0k/6IO+9mhGGu57TvVVhX dWYwSWImjDqtZG8weCBg0AioMqeVRWDjL1NUHfhLdvO50K8mryyIbtdsz8YZTkAURUfI B0tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FtEV5FAc4BfJQsqm1VvDTpjGsecEiJTSJzu6GUXAiOc=; b=CVpws/FMecIsxj59MP4aEeJo1E7A9pBXBCSC9ziruPaUhyKRtELMqCSujHXDLhkPax i8BhyXk30MpiIF9LtIf0nsaE0ZX3jFjLWySle4JLpP0o+CTSA/53b7D+11DXf7MXKBT1 GYqQmKsD5tcBO3N3ATnYGLIWuscx1/45XFAZTL/8eF13x5ZcNiPsrtnGCThKlXg4czfl K54VjdArWYj8bFAINeyWMx4sLfwgdYLqJ/rczKgPbl8EFFU2iCwADLz3Ow9JapMZGn3k cyBmhKWq4Uua+ll2WV2xsnUlp4rHQV3ozAxIuH67kwjo+wBqWhpI7VaFMA2aN62WaY6O KgLw==
X-Gm-Message-State: AHQUAuYhjEe1uazekoq3opxvbOUyUT/KSEKbRrI3ihThFYNRJxepwOuQ B/ovSgbm+YaQGBCrXPNLAqQreA==
X-Google-Smtp-Source: AHgI3Ibfs66RLUTqhOfPN/fW2aOQEdqSJP3qIbfnZRBE5nLQpnsca0Gw3QgHQrCISKoBKx9i3uitUQ==
X-Received: by 2002:a62:2e46:: with SMTP id u67mr1040638pfu.3.1550791744880; Thu, 21 Feb 2019 15:29:04 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id e9sm190652pfh.42.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 15:29:04 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F792578-A9A9-4BBA-93A1-A7BDCE8706E1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Thu, 21 Feb 2019 15:29:02 -0800
In-Reply-To: <>
Cc: Dick Franks <>, Tony Finch <>, dnsop <>, Paul Wouters <>, Joe Abley <>
To: Mark Andrews <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.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, 21 Feb 2019 23:29:07 -0000

On Feb 21, 2019, at 2:24 PM, Mark Andrews <> wrote:
> Implementation details are beyond the scope of RFCs.

Indeed they are.  My point is that if you want to be careful of memory usage or disk usage, you can be—there is no need to use a hash.   In essence, requiring us to use a hash is specifying an implementation detail that needn’t be specified: you can in fact implement this using a hash, although I wouldn’t.   It would be nice if I were not required to implement it that way, since I think that’s not actually going to work reliably.

> Also you mentioned caches which basically will never see these records unless they are queried for.

I mentioned caches because they are by far the biggest consumers of resources—authoritative name servers have much smaller memory footprints.   I assume the reason you think using hashes is a good idea and not a premature optimization is because you’ve done a lot of work with caching name servers, and are seeing this discussion through that lens.   That’s the wrong lens to be seeing it through.   This is only relevant for authoritative name servers, and in that case, storing the whole RR-to-be-deleted is fine.