Re: [Tzdist-bis] [calsify] tzdist and IANA -- estimating the operational parameters

Eliot Lear <> Thu, 18 July 2019 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 690E31208E4; Thu, 18 Jul 2019 09:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nz92uDhfXrU9; Thu, 18 Jul 2019 09:36:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A793F120630; Thu, 18 Jul 2019 09:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1815; q=dns/txt; s=iport; t=1563467780; x=1564677380; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=o7w7qBRSlgYslatEthFgPRgqWmoX0iivuId4zWU8DgU=; b=YRmR5uJlp0A21r9/ioYhQLFH8YCPmKzVa7HUfYO1C2QjIG4lvsjX45Ub b54tBo8YVS3FQ8ugrLJjhWvjjz2dJaJpRhvjIflnFLLkmBEfxeT13Oh3x OyKQLtwZc5s+cHCqqeW1AAXlpmrPpiruNO9o82Ea1INs2AtyzS1ouJgXD A=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.64,278,1559520000"; d="asc'?scan'208";a="14387268"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jul 2019 16:36:17 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id x6IGaGrD027455 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 16:36:17 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_37705F23-415C-473F-AB70-C2F18C94891E"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 18 Jul 2019 18:36:14 +0200
In-Reply-To: <>
Cc: " mailing list" <>, IETF-Calsify <>,, Paul Eggert <>, Daniel Migault <>, Martin Burnicki <>
To: Steve Crocker <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [Tzdist-bis] [calsify] tzdist and IANA -- estimating the operational parameters
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Extensions to Time Zone Data Distribution Service <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jul 2019 16:36:22 -0000

Hi Steve,

> On 18 Jul 2019, at 15:50, Steve Crocker <> wrote:
> Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS.  My first thought was the numbers are wildly different.  I jotted down a first cut at identifying the relevant operational parameters.  Perhaps the people proposing this service can flesh out the quantitative aspects.

My issue isn’t so much the size of entries.  Many entries can fit in a DNS packet *without* EDNS0.  It wouldn’t be wildly crazy to to use 2k as a good size.  The problem is 2k*O(10^9) (and soon O(10^10)) devices X an unknown frequency, because it is in part based on political considerations of the various jurisdictions.  The chaos coming to Europe soon will demonstrate this.  Also, I don’t think we should swear by the code in devices these days in terms of how they back off or what epsilons they use in their timers.

And then there are all the security aspects of that.  Shoving this stuff into the DNS would pretty much require DOH everywhere.