Re: [calsify] [Tzdist-bis] tzdist and IANA

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 <eggert@cs.ucla.edu> wrote:

> 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.
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>