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

[Eliot Lear <[e-mail]>]

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