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

[Michael Douglass <[e-mail]>]

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 ?
> 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.

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify