Subject: [Tzdist-bis] tzdist and IANA

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Jul 2019 16:35:05 -0400

Hi,

IANA is budgeting its next 4 year plan, they are taking comments until
end of July. In short inputs need to be provided before next IETF.

This has already been suggested in the past that IANA could operate a
tzdist server and I would like to get the opinion of the WGs on that.
Please provide your feed backs if possible by the end of the week, as we
expect to meet IANA people during the IETF in Montreal.

I am in favour of having a global system to distribute the time zones,
however, it seems maybe difficult to request IANA to operate the service
alone. I believe we need a more scalable system. I would rather suggest
that we work with IANA to build a scalable system within these four years.
This may in turn require a revision of the tzdist protocol.

I see the tzdist situation a bit similar as the one with the DNS root zone,
where IANA provides the data and the root zone being served by multiple
operators. In the case of tzdist I believe it would be helpful that IANA
may be one of the operators.

Yours,
Daniel

---

From: Michael Douglass <[email-masked]>
Date: Wed, 17 Jul 2019 16:42:12 -0400

Sounds good. We should include those currently maintaining the data as 
this probably implies some changes in that process.

On 7/17/19 16:35, Daniel Migault wrote:
> Please provide your feed backs if possible by the end of the week, as 
> we expect to meet IANA people during the IETF in Montreal.
>
> however, it seems maybe difficult to request IANA to operate the 
> service alone. I believe we need a more scalable system. I would 
> rather suggest that we work with IANA to build a scalable system 
> within these four years. This may in turn require a revision of the 
> tzdist protocol.
>
> I see the tzdist situation a bit similar as the one with the DNS root 
> zone, where IANA provides the data and the root zone being served by 
> multiple operators. In the case of tzdist I believe it would be 
> helpful that IANA may be one of the operators.
>
> Yours,
> Daniel
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 Jul 2019 16:46:23 -0400

I completely agree that we should approach IANA about hosting a 
root/primary TZDIST server, whether it be for iCalendar data (RFC5545) 
or TZif data (RFC 8536) or both.

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: David Thewlis <[email-masked]>
Date: Wed, 17 Jul 2019 15:20:31 -0700

I agree.  

> On Jul 17, 2019, at 13:46, Ken Murchison <[email-masked]> wrote:
> 
> I completely agree that we should approach IANA about hosting a root/primary TZDIST server, whether it be for iCalendar data (RFC5545) or TZif data (RFC 8536) or both.
> 
> 
> 
>> This has already been suggested in the past that IANA could operate a tzdist server and I would like to get the opinion of the WGs on that. Please provide your feed backs if possible by the end of the week, as we expect to meet IANA people during the IETF in Montreal.
>> 
>> I am in favour of having a global system to distribute the time zones, however, it seems maybe difficult to request IANA to operate the service alone. I believe we need a more scalable system. I would rather suggest that we work with IANA to build a scalable system within these four years. This may in turn require a revision of the tzdist protocol. 
>> 
>> I see the tzdist situation a bit similar as the one with the DNS root zone, where IANA provides the data and the root zone being served by multiple operators. In the case of tzdist I believe it would be helpful that IANA may be one of the operators. 
>> 
>> Yours, 
>> Daniel
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
> -- 
> Ken Murchison
> Cyrus Development Team
> Fastmail US LLC
> <murch.vcf>_______________________________________________
> calsify mailing list
> [email-masked]

---

From: Paul Eggert <[email-masked]>
Date: Wed, 17 Jul 2019 17:12:35 -0700

Daniel Migault wrote:
> alone.

Due to privacy concerns I'd rather have servers distribute the entire tz 
database compactly, rather than gather information about clients' preferred time 
zones as tzdist currently does. Is this improvement something that we could 
propose to IANA as well?

Currently the entire tzdb database (including version info and legal notice) 
fits into 22388 bytes compressed. I got this number by using lzip on tzdata.zi.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 Jul 2019 20:19:43 -0400

On 7/17/19 8:12 PM, Paul Eggert wrote:
> Due to privacy concerns I'd rather have servers distribute the entire 
> tz database compactly, rather than gather information about clients' 
> preferred time zones as tzdist currently does. Is this improvement 
> something that we could propose to IANA as well?

"Clients" of the IANA TZDIST server would either be primary or secondary 
servers and would be fetching ALL changed zones.  There should be no 
end-user clients talking to an IANA TZDIST server.

>
> Currently the entire tzdb database (including version info and legal 
> notice) fits into 22388 bytes compressed. I got this number by using 
> lzip on tzdata.zi.

There is no way to serve up raw tzdata via TZDIST because it can't be 
broken down into individual zones.  TZif is the format that can be used 
to distribute that data.

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Wed, 17 Jul 2019 17:40:35 -0700

Ken Murchison wrote:

> "Clients" of the IANA TZDIST server would either be primary or secondary servers 
> and would be fetching ALL changed zones.  There should be no end-user clients 
> talking to an IANA TZDIST server.

True, I was worried more about privacy between clients and the secondary servers.

> There is no way to serve up raw tzdata via TZDIST

Yes, and part of the proposal would be to improve TZDIST so that clients can 
obtain the entire tzdb efficiently. For secure clients there should be little 
reason to request just a subset of tzdb when the entire database is so small.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Jul 2019 22:13:47 -0400

If I understand correctly the suggestion is to have tzdist server uploading
the tzdata from IANA and client connecting to these tzdist servers. While
some local network may have a local tzdist server, I would have expected
that we could end up in having a global tzdist service that could be used
by default by any client - let say tzdist.org. of course tzdist.org could
be operated by multiple operators, and one of these could be the IANA. I am
wondering if that is something in line with the latest messages.

Retrieving the tzdb from IANA for example by a tzdist server is already
something that can be done via FTP HTTP for the full tzdb or incrementally
via rsynch. If IANA is operating a tzdist server, we could use a request
with a "changedsince" parameter. Using the mechanism defined by tzdist
seems to me appropriated as the root zone is distributed using a
distribution master. My understanding is that we define an efficient way to
do that in tzdist. Is that correct ?

If the iana is not expected to serve client, I am wondering how the
difference between clients and secondary would be made. Do we expect
specific prmary/secondary relation being pre-agreed ?

I understand Paul's suggestion as a generic suggestion that client
generally should retrieve the full tzdb rather than a specific tz, in which
case, this request should be optimised. As I understand it the privacy
concern is more associated to the information leaked to the tzdist server
as I assume that all exchanges would be performed over TLS. One concern I
have regarding the use of TLS is that it protects the channel to the tzdist
server, but I am not sure how the client can effectively check the data is
in accordance to the one distributed by IANA. I am also wondering if we
should not look at mechanisms that authenticate the data. This could in
return prevent the need to use TLS.

Yours,
Daniel

On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert <[email-masked]> wrote:

> servers

---

From: Michael Douglass <[email-masked]>
Date: Wed, 17 Jul 2019 23:03:07 -0400

I guess my feeling on the privacy issues is that it should be a client 
choice. Certainly for a mobile device such as a phone the entire data 
set would be reasonable - especially if there were a way to reduce it to 
currently active data.

However, for small devices - often with a fixed location - being able to 
retrieve a single zone is probably appropriate.

I suspect the current approach we have implemented for updating 
downstream servers (though all downstream servers are really clients) 
would work for anybody. However - it does assume that we can have a 
sequence#/timestamp per zone

On 7/17/19 22:13, Daniel Migault wrote:
> If I understand correctly the suggestion is to have tzdist server 
> uploading the tzdata from IANA and client connecting to these tzdist 
> servers. While some local network may have a local tzdist server, I 
> would have expected that we could end up in having a global tzdist 
> service that could be used by default by any client - let say 
> tzdist.org <http://tzdist.org>. of course tzdist.org 
> <http://tzdist.org> could be operated by multiple operators, and one 
> of these could be the IANA. I am wondering if that is something in 
> line with the latest messages..
>
> Retrieving the tzdb from IANA for example by a tzdist server is 
> already something that can be done via FTP HTTP for the full tzdb or 
> incrementally via rsynch. If IANA is operating a tzdist server, we 
> could use a request with a "changedsince" parameter. Using the 
> mechanism defined by tzdist seems to me appropriated as the root zone 
> is distributed using a distribution master. My understanding is that 
> we define an efficient way to do that in tzdist. Is that correct ?
I don't know there is any difference between clients and secondary 
servers. I would expect servers nearer the root to not be open to 
anybody but only to a small set of pre-registered servers as you 
suggest. I suspect that vendors - if they use this service would want to 
provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS 
etc etc
> generally should retrieve the full tzdb rather than a specific tz, in 
> which case, this request should be optimised. As I understand it the 
> privacy concern is more associated to the information leaked to the 
> tzdist server as I assume that all exchanges would be performed over 
> TLS. One concern I have regarding the use of TLS is that it protects 
> the channel to the tzdist server, but I am not sure how the client can 
> effectively check the data is in accordance to the one distributed by 
> IANA. I am also wondering if we should not look at mechanisms that 
> authenticate the data. This could in return prevent the need to use TLS.

I'm guessing the use of tls for most isn't an issue. tzdata is fairly 
slow moving and we're probably considering a once or twice a day check. 
Nothing compared to your facebook interactions.

For small devices though it might be useful on a per zone basis

>
> Yours,
> Daniel
>
>
>
>
>
>
>
>
>
> On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Ken Murchison wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Jul 2019 08:02:56 +0200

Hi everyone,

While the IANA does a great job at servicing our assigned number needs and delivering the TZ database to developers, they is not set up, nor do they have any experience, to handle the load that end clients could place on them.  Moreover, they are in no position to support millions of people if something goes wrong.  And make no mistake: something will go wrong.  I would be okay with a limited tzdist service for those who are going to be distributing the data themselves, but the order of receivers should be on 100s not millions.

Eliot

> On 18 Jul 2019, at 05:03, Michael Douglass <[email-masked]> wrote:
> 
> I guess my feeling on the privacy issues is that it should be a client choice. Certainly for a mobile device such as a phone the entire data set would be reasonable - especially if there were a way to reduce it to currently active data.
> 
> However, for small devices - often with a fixed location - being able to retrieve a single zone is probably appropriate.
> 
> I suspect the current approach we have implemented for updating downstream servers (though all downstream servers are really clients) would work for anybody. However - it does assume that we can have a sequence#/timestamp per zone
> 
>> If I understand correctly the suggestion is to have tzdist server uploading the tzdata from IANA and client connecting to these tzdist servers. While some local network may have a local tzdist server, I would have expected that we could end up in having a global tzdist service that could be used by default by any client - let say tzdist.org <http://tzdist.org/>. of course tzdist.org <http://tzdist.org/> could be operated by multiple operators, and one of these could be the IANA. I am wondering if that is something in line with the latest messages..
>> 
>> Retrieving the tzdb from IANA for example by a tzdist server is already something that can be done via FTP HTTP for the full tzdb or incrementally via rsynch. If IANA is operating a tzdist server, we could use a request with a "changedsince" parameter. Using the mechanism defined by tzdist seems to me appropriated as the root zone is distributed using a distribution master. My understanding is that we define an efficient way to do that in tzdist. Is that correct ?
>> 
>> If the iana is not expected to serve client, I am wondering how the difference between clients and secondary would be made. Do we expect specific prmary/secondary relation being pre-agreed ?
> I don't know there is any difference between clients and secondary servers. I would expect servers nearer the root to not be open to anybody but only to a small set of pre-registered servers as you suggest. I suspect that vendors - if they use this service would want to provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS etc etc
>> 
>> I understand Paul's suggestion as a generic suggestion that client generally should retrieve the full tzdb rather than a specific tz, in which case, this request should be optimised. As I understand it the privacy concern is more associated to the information leaked to the tzdist server as I assume that all exchanges would be performed over TLS. One concern I have regarding the use of TLS is that it protects the channel to the tzdist server, but I am not sure how the client can effectively check the data is in accordance to the one distributed by IANA. I am also wondering if we should not look at mechanisms that authenticate the data. This could in return prevent the need to use TLS.
> I'm guessing the use of tls for most isn't an issue. tzdata is fairly slow moving and we're probably considering a once or twice a day check. Nothing compared to your facebook interactions.
> 
>> On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert <[email-masked] <mailto:[email-masked]>> wrote:
>> Ken Murchison wrote:
>> 
> Tzdist-bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist-bis

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 18 Jul 2019 10:29:23 +0200

Hi all,

Eliot Lear wrote:
> Hi everyone,
> 
> While the IANA does a great job at servicing our assigned number needs
> and delivering the TZ database to developers, they is not set up, nor do
> they have *any* experience, to handle the load that end clients could
> place on them.  Moreover, they are in no position to support millions of
> people if something goes wrong.  And make no mistake: something will go
> wrong.  I would be okay with a limited tzdist service for those who are
> going to be distributing the data themselves, but the order of receivers
> should be on 100s not millions.

Wouldn't it be nice to have an infrastructure similar to what the NTP
pool provides for time synchronization?

https://www.ntppool.org/en/

There could be one or more primary servers that might have restricted
access, and there could be servers operated by companies, ISPs, or
volunteers that get the information from the primaries and make the
service available to customers or the general public.

Depending on their preferences or policies, users could choose specific
servers provided by the company they work for, or by their ISP.

If none of those is appropriate they could just use the TZDIST pool
where a DNS server provides the IP address of a nearby available TZDIST
server, just like this is done for the NTP pool.

Of course it would be good if the final client could verify that the
provided TZ information is authentic. I'm not sure if this can be
achieved by access via https, or if the TZ/TZDIST data should include a
cryptographic signature.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Jul 2019 10:40:21 +0200

> On 18 Jul 2019, at 10:29, Martin Burnicki <[email-masked]> wrote:
> 
> Hi all,
> 
> Eliot Lear wrote:
>> Hi everyone,
>> 

I guess I would want to see commitment from those who provide TZ service to their customers today to go to such a new service before investing a lot of money.  Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the others want to use it?  I also realize that ICANN is well positioned to fund this sort of thing, but it is not clear to me that it is right for them to do so.  There has to be a real need, and those who really need it perhaps should foot the bill.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Thu, 18 Jul 2019 10:00:59 +0100

> should be on 100s not millions.

The whole basis of the tzdist setup was that it provides a distributed 
means of serving the data. At the top level there is a need for primary 
publishers and since IANA *IS* a primary source then that material does 
need to be published somehow. The ONE think that is important here is 
that any publisher should properly identify the range of data that it is 
providing in addition to being able to service the differences between 
the current version of a rule set and that the client is actively using 
and any later changes. TZDIST is not simply a means of serving a single 
view of the TZ data, it is intended to be able to also provide an 
indication that the rule set that was used initially to normalise data 
has now changed. Bypassing that mechanism by only providing a current 
monolithic dump of the data is not what was intended and is why it is 
based on individual timezone identifiers, and each can be developed 
separately as further historic material becomes available.

We need to at least start to build the seeds of publishers but 
personally I'm not sure IANA is the right starting point since TZ is 
already a truncated data publisher ...

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 18 Jul 2019 11:41:07 +0200

> I guess I would want to see commitment from those who provide TZ service to their customers today to go to such a new service before investing a lot of money.  Would Red-hot, Apple, Microsoft, Debi…

I'm working at Meinberg
https://www.meinbergglobal.com/

and we are manufacturing NTP/PTP servers, beside related time
synchronization stuff.

In the past, whenever governments as of Egypt, Morocco, etc. decided to
start or end DST just a couple of days before this really happens we get
support requests from industries, telecommunication companies, etc.,
asking if our time servers could fix the problem to update the TZ data
quickly enough.

We always have to tell them they need to wait until a new TZ DB has been
released, and then hope that their OS maintainers (Microsoft, Apple,
Linux distros, etc.) pick up the new TZ DB version and provide a
software/firmware update just to provide the latest changes quickly.

Providing these updates also requires quite some effort for the
maintainers, and it would be much easier for them if this kind of
information could be updated automatically, which should also be faster
than with manual intervention required.

TZ data must not be requested from a server as often as the current
time, so I think that even if the data size is larger than an NTP packet
the overall load compared to NTP will not be much higher than for a
server that provides NTP services, and if I remember correctly then data
only needs to be transferred if changes have become available.

So I think this type of service and its advantages just need to be made
more public, to let the OS maintainers learn that they have less work
with rolling out and deploying software updates if they just use TZDIST.

I'd expect that a TZDIST pool could be operated by volunteers, just like
the NTP pool.

Martin

---

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Jul 2019 09:07:57 -0400

adding the tz mailing in the discussion

Yours,
Daniel

On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki <
[email-masked]> wrote:

> > I guess I would want to see commitment from those who provide TZ service
> to their customers today to go to such a new service before investing a lot
> of money.  Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the
> others want to use it?  I also realize that ICANN is well positioned to
> fund this sort of thing, but it is not clear to me that it is right for
> them to do so.  There has to be a real need, and those who really need it
> perhaps should foot the bill.
> >
>
> I'm working at Meinberg

---

From: Steve Crocker <[email-masked]>
Date: Thu, 18 Jul 2019 09:50:38 -0400

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.

Thanks,

Steve

---

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Jul 2019 10:26:22 -0400

> perhaps should foot the bill.

If these companies are on the list it would be good they share their
thoughts, otherwise it would be good to contact them if any of you have
some contacts.
Yours,
Daniel

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Jul 2019 15:32:26 +0100

Steve Crocker <[email-masked]> wrote:

> served in a fashion similar to DNS.

We could just use the DNS :-) As Paul pointed out, TZif files are not
very big.

I have experimentally shoved the zoneinfo files from my workstation into a
DNS zone I happen to have lying around. I've deflated (RFC 1950) each file
(RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The
result appears below as a hex blob (RFC 3597) which does not quite fit in
the Ethernet MTU, but you can get the answer over UDP if you allow EDNS
with fragmentation. It's signed with DNSSEC so you can be sure I am to
blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg

; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1420
; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good)
;; QUESTION SECTION:
;London.Europe.tz.dotat.at. IN TYPE29818

;; ANSWER SECTION:
London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at.
London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 (
                                20190728110326 20190718100326 56700 dotat.at.
                                R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI
                                voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG
                                aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru
                                hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= )
GB.tz.dotat.at.         3412 IN TYPE29818 \# 1751 (
				789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9
                                34CDFC36914B4BEE8D6DB9FCD22FD208439666691969
                                3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026
                                26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3
                                B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7
                                A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336
                                9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE
                                B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA
                                D34F159985AEDD66615E75FD59E179BD6873825EBCF5
                                3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C
                                6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB
                                AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD
                                FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4
                                A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9
                                26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E
                                B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14
                                62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53
                                EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC
                                8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9
                                317364C4687DB45713F3B347CCB1880AE678E4627D22
                                28441754F39882E2BB7561C9287D32FF8C3E75A0B73E
                                BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0
                                287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657
                                5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A
                                1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7
                                D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59
                                2D5361A75B579C76C3545A5255571EF5935133C24C95
                                9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9
                                E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105
                                AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88
                                51F7457B54F0C066AA41684BD5B05B776954A1A66ADC
                                A4A934BEF2A08404549690BC40695278411EC82C92D0
                                ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B
                                BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C
                                512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE
                                F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6
                                6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755
                                BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63
                                A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E
                                4F4E965E0943A4F74309E289EE2A4FD488953EA121D2
                                E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901
                                EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8
                                93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0
                                3A22430BD2645849920CDF9222CF1DF0C888F47E9290
                                334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58
                                25C5D7502F86D755A33B5F532F5571A9E466D525F9FC
                                1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B
                                3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF
                                5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE
                                BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF
                                F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515
                                AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7
                                D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC
                                5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718
                                B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8
                                DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23
                                B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9
                                FF4803900E38DA16203D70B44D40BA80B401E903D208
                                A413482B905E38DA6620DD40DA81F4036988A3ED88A3
                                6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41
                                7A833407E90ED21EA43F4883900E212D427A843409E9
                                12D22647DB27A45148A7905621BD429A85740B6917D2
                                2FA46148C79096213D439A86740D691BD23747DB38A4
                                7348EB90DE21CD43BAC7DF1AED43FA873410E920D242
                                47DB43A4898EB68B481B913E228D443AE91C12DB4AA4
                                974833916E22ED44FA893414E928D252A4A748531D6D
                                5791B6227D451A8B7416692DD25BA4B9487791F622FD
                                451A8C74186931D263A4C98EB6CB489B1D6D9F914623
                                9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5
                                48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4
                                F948F791F623FD473600B203902D80EC01641320BB00
                                D906C83E70B41B01D9098E762B207B01D90CC86E40B6
                                03B21F900D81EC08644B207B02D914C8AE40B605B22F
                                1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64
                                83203B04D922C81E413609B24B906D82EC1364A3203B
                                C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C
                                B265903D836C1A64D720DB06D937C8C641768EA3DD3A
                                C8DE71B49B07D93DC8F641F60FB281901D846C21640F
                                B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C
                                3C3426DCCDAB805F0162E35BFB )
GB.tz.dotat.at.         3412 IN RRSIG TYPE29818 5 4 3600 (
                                20190728110326 20190718100326 56700 dotat.at.
                                JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v
                                ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j
                                4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq
                                +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jul 18 15:15:18 BST 2019
;; MSG SIZE  rcvd: 2209

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, East Faeroes: Mainly southerly 4 or 5, increasing 6 at times.
Moderate, occasionally slight. Occasional rain or showers. Moderate or good,
occasionally poor.

---

From: Michael Douglass <[email-masked]>
Date: Thu, 18 Jul 2019 11:52:34 -0400

> We could just use the DNS :-) As Paul pointed out, TZif files are not

DNS keeps turning up as a suggestion. However, just because tz 
distribution has some vague similarity to DNS doesn't make it a good idea.

I'm sure it can be done but a simple RESTful interface over https is 
simpel and easily implemented.

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 18 Jul 2019 17:12:51 +0100

We already have a REST-like standard defined for carrying TZ data - RFC 
7808. It also appears based upon previous discussions that very few, if 
any real world implementations and deployments which exist. Perhaps this 
is because of the complexity of the standard, and maybe defining a 
simpler subset might be more appealing for implementations.

Regards

---

From: Michael Douglass <[email-masked]>
Date: Thu, 18 Jul 2019 12:20:33 -0400

On 7/18/19 12:12, Thomas Peterson wrote:
> We already have a REST-like standard defined for carrying TZ data - 
> RFC 7808.
I know - I'm one of the authors
> It also appears based upon previous discussions that very few, if any 
> real world implementations and deployments which exist. Perhaps this 

I can assure you it's very simple to implement. There are at least 3 
implementations.

The major issue as far as I can tell is getting some organization(s) to 
agree to host a root service we can build out from. Without that it's 
going nowhere.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Jul 2019 18:36:14 +0200

Hi Steve,

> On 18 Jul 2019, at 15:50, Steve Crocker <[email-masked]> 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.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Thu, 18 Jul 2019 13:15:54 -0700

> flesh out the quantitative aspects.

Here are some estimates. There is no central TZDIST server now, so all the 
non-size estimates are for if/when that happens. The estimated rate of change 
for these numbers is all zero, except for the database size where I'd estimate a 
growth of 5%/year (this is just off the top of my head).

Frequency of database update: 18 times per year has been the worst case since 
the project started in the 1980s. Recently updates have occurred three to ten 
times per year.

Frequency of access: If we're assuming a pull model like TZDIST with primary and 
secondary servers, I would expect queries once every hour-or-so from each 
downstream server that wants to be up-to-date. Usually the response will be 
"nothing has changed".

Required response time: Most clients and servers can be expected to have a 
(possibly-stale) copy of the data already, which they can fall back on. So I 
would say "minutes".

Required uptime: Again, not crucial. I would say 90% would be enough.

For sizes, it depends on data format and whether you want all the data.

Size of entire tzdb database (including all time zone history, version info, and 
legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB 
compressed via gzip, 22 kB compressed via lzip.

Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB 
uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone 
history but omits version info and legal notices.

Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 
instead of attempting to work around bugs in older applications: 216 kB 
uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.

I don't know how to compute the size of tzdb converted into iCalendar form, but 
my guess is that it'd be the same order-of-magnitude as the TZif files.

All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 18 Jul 2019 16:26:11 -0400

On 7/18/19 4:15 PM, Paul Eggert wrote:
> Here are some estimates. There is no central TZDIST server now, so all 
> the non-size estimates are for if/when that happens. The estimated 
> rate of change for these numbers is all zero, except for the database 
> size where I'd estimate a growth of 5%/year (this is just off the top 
> of my head).
>
>
> Frequency of database update: 18 times per year has been the worst 
> case since the project started in the 1980s. Recently updates have 
> occurred three to ten times per year.
>
> Frequency of access: If we're assuming a pull model like TZDIST with 
> primary and secondary servers, I would expect queries once every 
> hour-or-so from each downstream server that wants to be up-to-date. 
> Usually the response will be "nothing has changed".
>
> Required response time: Most clients and servers can be expected to 
> have a (possibly-stale) copy of the data already, which they can fall 
> back on. So I would say "minutes".
>
> Size of entire tzdb database (including all time zone history, version 
> info, and legal notices), in minimal source-code (text) form: 111 kB 
> uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip.
>
> Size of entire tzdb database in binary (TZif) form in traditional 
> form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This 
> includes all time zone history but omits version info and legal notices.
>
> Same size, but with zic's new '-b slim' option that relies on Internet 
> RFC 8536 instead of attempting to work around bugs in older 
> applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.
>
> I don't know how to compute the size of tzdb converted into iCalendar 
> form, but my guess is that it'd be the same order-of-magnitude as the 
> TZif files.

My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is 
also 77kB tar+gz.

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Steve Crocker <[email-masked]>
Date: Thu, 18 Jul 2019 16:30:08 -0400

Paul and Ken,

Thanks for these estimates.

It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.

Steve

Sent from my iPhone

> On Jul 18, 2019, at 4:26 PM, Ken Murchison <[email-masked]> wrote:
> 
> 
>> Here are some estimates. There is no central TZDIST server now, so all the non-size estimates are for if/when that happens. The estimated rate of change for these numbers is all zero, except for the database size where I'd estimate a growth of 5%/year (this is just off the top of my head).
>> 
>> 
>> Frequency of database update: 18 times per year has been the worst case since the project started in the 1980s. Recently updates have occurred three to ten times per year.
>> 
>> Frequency of access: If we're assuming a pull model like TZDIST with primary and secondary servers, I would expect queries once every hour-or-so from each downstream server that wants to be up-to-date. Usually the response will be "nothing has changed".
>> 
>> Required response time: Most clients and servers can be expected to have a (possibly-stale) copy of the data already, which they can fall back on. So I would say "minutes".
>> 
>> Size of entire tzdb database (including all time zone history, version info, and legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip.
>> 
>> Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone history but omits version info and legal notices.
>> 
>> Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 instead of attempting to work around bugs in older applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.
>> 
>> I don't know how to compute the size of tzdb converted into iCalendar form, but my guess is that it'd be the same order-of-magnitude as the TZif files.
> 
> 
> My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is also 77kB tar+gz.
> 
> 
> 
>> 
> <murch.vcf>

---

From: Paul Eggert <[email-masked]>
Date: Thu, 18 Jul 2019 13:51:11 -0700

> It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.

Sorry, I shouldn't have distracted the performance discussion by mentioning that 
verbiage. It's so small that eliminating it isn't worth the effort unless one is 
trying to win a compression contest. Here's a complete copy of the verbiage:

# This zic input file is in the public domain.

---

From: Steve Crocker <[email-masked]>
Date: Thu, 18 Jul 2019 16:53:44 -0400

:)

Sent from my iPhone

> On Jul 18, 2019, at 4:51 PM, Paul Eggert <[email-masked]> wrote:
> 
> Steve Crocker wrote:
> Sorry, I shouldn't have distracted the performance discussion by mentioning that verbiage. It's so small that eliminating it isn't worth the effort unless one is trying to win a compression contest. Here's a complete copy of the verbiage:
>

---

From: Paul Eggert <[email-masked]>
Date: Thu, 18 Jul 2019 15:54:30 -0700

Here are some other thoughts about any potential IANA effort in this area:

* As others have mentioned, the effort should address authentication of the 
timezone data. It would be helpful to have a real authentication expert in on 
this, since we want something simple and scalable and workable downstream (see 
below).

* Each tzdb release comes with a version number like "2019b", development 
commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers 
often make minor changes to the data, and some append a suffix to the version 
number to indicate this. The mechanism for publishing this number is specified 
only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort 
would do something more specific. Downstream modifications will complicate data 
authentication.

* Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab 
that contain vague geographical information associated with each tzdb entry. (In 
some cases this vagueness is intentional, to avoid running into political 
disputes.) These files are not covered by TZDIST but some POSIX-style clients 
use them. How should metadata like this be addressed?

* Each tzdb release has an auxiliary data file 'leapseconds' that is widely used 
by clients running NTP and related software. TZDIST has a "leapseconds" action 
that conveys the information in a different format, and we would need to make 
sure that this all hooks up correctly.

* It'd be helpful to support not only TZDIST, but also a reasonably simple 
protocol, presumably based on HTTPS transfer of the data since HTTPS is widely 
supported. This could be used by platforms that don't support TZDIST, or that 
need auxiliary metadata that is outside the scope of TZDIST. For example, many 
NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap 
seconds data format.

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 19 Jul 2019 06:13:10 +0000

> thoughts, otherwise it would be good to contact them if any of you have

I'm not working at any of these companies, but my guess is that these 
companies are using the data from IANA, and integrating it into their 
application updating process while verifying it with information they 
obtain from their local subsidiaries. This verification, and maybe in 
some instances some political considerations, may be the main blocks for 
not switching to a totally automated updating system. In any case, the 
number of such companies is small, and for them, the current 
distribution system (directly from IANA) is completely sufficient.

Because of the lead times involved, it's sufficient in most cases to 
deploy the information via the nowadays well established OS update 
channels (e.g. Patch Tuesday,...). Most applications then get the 
information from the OS.

As for 'foot the bill', the various OS makers are already doing so. The 
question is whether they would be ready to foot another, separate bill.

Independent applications (including maybe some programming languages) 
that don't rely on OS information may be the best candidates for 
benefiting from a new distribution scheme.

In a separate mail, a reliability requirement of 90% was mentioned. This 
is okay if this translates into 2h off per day, but it would be 
insufficient if it translated into 1 month off per year, in a single 
block. So 90% has to be qualified.

Regards,   Martin.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Jul 2019 09:50:16 -0400

Hi

The calext WG met yesterday. The minutes will be uploaded soon. It has been
agreed that the discussion of the tzdist system should not be split over
three mailing lists and will be done on the   tzdist-bis[1] mailing list.

Please continue the discussion on that mailing list.

Yours,
Daniel

[1] https://www.ietf.org/mailman/listinfo/Tzdist-bis