Subject: [Tzdist] DHCP option for tzdist servers available?

From: Martin Burnicki <[email-masked]>
Date: Mon, 06 Oct 2014 15:45:36 +0200

Hello folks,

I know this is not fully on-topic here, but I'd like to ask if someone 
knows whether a well-known DHCP option for tzdist server(s) has already 
been assigned.

For example, by using

   option ntp-servers 172.16.3.9;

an ISC DHCP server can be configured to pass the IP address of one or 
more NTP servers on the local network to the DHCP clients, so 
workstations can be configured automatically for the IP address from 
which they can get the current time via NTP protocol. The numeric option 
code for "ntp-servers" is 42, if I remember correctly.

It would be great if a similar DHCP option code could be (or already had 
been) assigned for tzdist server(s).

Since the DHCP option code doesn't depend on details of the tzdist 
protocol the number can be assigned very early, so once the tzdist 
protocol has been fully determined and implemented it would be easy to 
use it very quickly in installations since DHCP servers and clients were 
already aware of this option.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Oct 2014 15:47:24 +0200

There is RFC 4833 for the TimeZone *name*, but not servers.  Before we
create such an option for servers I would like to know that it would be
used.

On 10/6/14, 3:45 PM, Martin Burnicki wrote:
> knows whether a well-known DHCP option for tzdist server(s) has
> already been assigned.
>
> For example, by using
>
> which they can get the current time via NTP protocol. The numeric
> option code for "ntp-servers" is 42, if I remember correctly.
>
> It would be great if a similar DHCP option code could be (or already
> had been) assigned for tzdist server(s).
>
> use it very quickly in installations since DHCP servers and clients
> were already aware of this option.
>
> Martin
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>
>

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 6 Oct 2014 16:27:10 +0200

On Mon, Oct 6, 2014 at 3:47 PM, Eliot Lear <[email-masked]> wrote:
> There is RFC 4833 for the TimeZone
That RFC contains no occurrence of "TimeZone".

There are some of "timezone", "Timezone", "time zone".

They seem to refer to the concept of time zone as /used/ by the IANA
TZDB: a region.

tzdist-service uses another concept named "time zone": a description
[of practices].

> *name*,
In RFC 4833 it may refer to the concept of an identifier, specifically
an IANA TZID.

tzdist-service also has a concept including the term "identifier",
namely "time zone identifier", but it identifies descriptions, not
regions.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 06 Oct 2014 16:57:07 +0200

Hi Eliot,

thanks for the fast reply.

> create such an option for servers I would like to know that it would be

I'm software developer at Meinberg Funkuhren
http://www.meinbergglobal.com/

Every year when DST starts or ends in certain countries where this is 
only announced very shortly before it actually happens we get a number 
of requests from customers who want to buy NTP servers from us providing 
their network devices with the correct *local* time.

Every time I have to explain to those customers that:

- NTP doesn't provide local time, only UTC

- The TZ data base (or Windows registry) needs to be updated on *every* 
machine which requires the updated rules for their time zone.

The general problem with the deployment is that

- A new version of the TZ data base needs to be rolled out first

- For each Unix version or Linux distro a *firmware* update needs to be 
provided by the package maintainers of the distribution. Often there 
even need to be several packages for different versions of the same 
Linux distribution. Similarly, Microsoft has to roll out updates for 
different Windows versions.

- The users have to figure out which versions of the updates they need, 
and apply them correctly. Sometimes there isn't even an update available 
for a particular older version of an OS, so upgrading the TZ rules isn't 
possible even though it is only a modified set of data (TZ rules).

The tzdist protocol is the perfect solution for these users: Once the TZ 
database update has been rolled out, company servers could pull the 
updates from the "official" servers, and local workstations could pull 
the latest TZ rules from the company server(s). This is a *huge* 
simplification for the folks who have to maintain IT infrastructure in 
countries like Israel, Morocco, or Egypt, and it would provide much 
benefit to other users/admins, too.

And the best thing would be if they could just distribute the address of 
their company's tzdist server via DHCP, in which case all clients could 
easily be configured to let them know where to get the tzdist updates from.

If the client workstations get only a single time zone name and/or rule 
from the DHCP server then the DHCP server needs to be reconfigured 
whenever the TZ rule changes.

In case of the new tzdist protocol the DHCP server only needs to provide 
the IP address of the server which provides tzdist services, and every 
machine can pull the latest rules for the time zone(s) it is interested 
in from that server.

So I'm *sure* this will be used.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Oct 2014 18:54:09 +0200

Here's the question to you Martin:

Will your software make use of a local tzdist server OR will you
preconfigure a tzdist server that your company offers or contracts for?
If it's the latter then you don't need a DHCP option.  If it's the
former, then maybe you do.

Eliot

On 10/6/14, 4:57 PM, Martin Burnicki wrote:
> of requests from customers who want to buy NTP servers from us
> providing their network devices with the correct *local* time.
>
> - The TZ data base (or Windows registry) needs to be updated on
> *every* machine which requires the updated rules for their time zone.
>
> - For each Unix version or Linux distro a *firmware* update needs to
> be provided by the package maintainers of the distribution. Often
> there even need to be several packages for different versions of the
> same Linux distribution. Similarly, Microsoft has to roll out updates
> for different Windows versions.
>
> - The users have to figure out which versions of the updates they
> need, and apply them correctly. Sometimes there isn't even an update
> available for a particular older version of an OS, so upgrading the TZ
> rules isn't possible even though it is only a modified set of data (TZ
> rules).
>
> The tzdist protocol is the perfect solution for these users: Once the
> TZ database update has been rolled out, company servers could pull the
> And the best thing would be if they could just distribute the address
> of their company's tzdist server via DHCP, in which case all clients
> could easily be configured to let them know where to get the tzdist
> updates from.
>
> If the client workstations get only a single time zone name and/or
> rule from the DHCP server then the DHCP server needs to be
> reconfigured whenever the TZ rule changes.
>
> In case of the new tzdist protocol the DHCP server only needs to
> provide the IP address of the server which provides tzdist services,
> and every machine can pull the latest rules for the time zone(s) it is
> interested in from that server.
>

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 6 Oct 2014 19:04:16 +0200

> former, then maybe you do.

Why does it matter what Martin's organization does if what he
described is a plausible use case for DHCP?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 06 Oct 2014 20:33:50 +0200

Eliot, Tobias,

> described is a plausible use case for DHCP?

;-)

In fact I don't know if the devices manufactured by the company I'm 
working for will ever provide tzdist services, though this could be a 
good additional feature since it is related to what they are doing now, 
providing accurate time via NTP, PTP and similar mechanisms.

I am pretty sure, though, that Meinberg is not going to offer tzdist 
services which need to be licensed by customers. My basic idea would be 
that existing public servers could also probide tzdist services, similar 
as the NTP pool servers provide accurate time in a public way.

What I mentioned in my initial email on this topic was just to point out 
how IT admins sometimes desparately try wrong approaches, e.g. 
distibuting local time via NTP instead of UTC, just to work around 
problems caused by the legeslative power of the countries they live in.

In my opinion tzdist is an excellent way to get a proper solution, and a 
DHCP option telling the IP address of a tzdist server would make 
maintenance once more easier, regardless whether the IP address provided 
by DHCP belongs to a LANTIME device manufactured by Meinberg, or an 
existing Unix or Windows server in the company which also provides 
tzdist services.

If a DHCP option code is assigned *now* then a complete tzdist 
infrastructure can be implemented as soon as the standardization of the 
protocol is finished. If the DHCP option code is only assigned after the 
protocol has already been released it will take much more time until 
admins can use the new tzdist protocol in an easyand common way.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Oct 2014 20:36:31 +0200

Hi Tobias,

> described is a plausible use case for DHCP?

What I am getting at is whether or not it is a plausible case that
*anyone* would offer this service on their own.  Also, there is a
separate question, which is whether or not this is better handled by an
SRV record, which is already specified in the draft.

Eliot

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 06 Oct 2014 20:52:48 +0200

Eliot,

Eliot Lear wrote:
>> On Mon, Oct 6, 2014 at 6:54 PM, Eliot Lear<[email-masked]>  wrote:

The idea behind this is that just like with DNS or NTP services there is 
some "authoritative server", but noch each and every little embedded 
device needs to contact that server directly.

Instead, internet providers or companies with a huge number of network 
nodes could set up one or two own tzdist servers polling the 
"authoritative server(s)" for updates, and providing tzdist services 
inside their companies or (in case of internet providers) for their 
customers.

Similarly as a DHCP server today tells which DNS or NTP servers its 
client should use, it could tell which tzdist server is available for 
its clients.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Oct 2014 20:56:09 +0200

Hi,

On 10/6/14, 8:52 PM, Martin Burnicki wrote:
>
> The idea behind this is that just like with DNS or NTP services there
> is some "authoritative server", but noch each and every little
> embedded device needs to contact that server directly.
>

I'm not opposed to the idea on principle.  I would like to hear from
others, and I will open an issue to track it.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Mon, 06 Oct 2014 20:13:54 +0100

> client should use, it could tell which tzdist server is available for

The problem I see here is that this would have to be a fully
un-truncated service. If a DHCP server provides a truncated service the
default the users see may be restricted.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 06 Oct 2014 21:28:24 +0200

Lester,

> default the users see may be restricted.

If an internet provider operates a DHCP server for his customers, or the 
IT department od a company provides DHCP services for the workstations 
of their employees, don't you think the amount of data to be provided by 
a tzdist server is tiny compared to other kind of data?

Nowadays, without tzdist, usually the whole TZ DB is deployed to 
workstation computers anyway, so it should not be a problem for an IT 
admin to provide a full set of tzdist services for the whole company, so 
that every user has a current version of the time zoe available he 
prefers to work in.

Martin

---

From: Lester Caine <[email-masked]>
Date: Mon, 06 Oct 2014 20:56:49 +0100

> that every user has a current version of the time zoe available he

Not if TZ has it's way ... only a truncated version is currently
supported by default!

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 09 Oct 2014 11:57:44 -0400

Hi Lester,

> Not if TZ has it's way ... only a truncated version is currently

Yes, but that fact is advertised to the client via the capabilities so 
client that care about getting the full data can choose to use an 
alternative source. Remember, in most cases, the options served up by DHCP 
(DNS, NTP etc) can be overridden on the client.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 09 Oct 2014 12:02:08 -0400

Hi Eliot,

> others, and I will open an issue to track it.

I wanted to avoid going into the "discovery" aspect of tzdist too much 
because there are many ways it could be done. Right now SRV seems like the 
best internet-wide solution which is why it is present. But there are many 
possible "local area" solutions: obviously DHCP is one, mDNS (aka Bonjour) 
is another. I am not sure the base spec should tackle the "local area" 
discovery topic at present, until we see that there is a real demand for 
that and what form that demand takes.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Thu, 09 Oct 2014 17:17:10 +0100

On 09/10/14 16:57, Cyrus Daboo wrote:
> alternative source. Remember, in most cases, the options served up by
> DHCP (DNS, NTP etc) can be overridden on the client.

I just want to make sure that it does not drop through the gaps ;)
Currently it may not be clear to a user just where the range of data
available stops. While it is the publishers problem to be honest on
reliably publishing their capabilities, it may not be so obvious to
users that their default 'service' may not actually be complete.

I think all I'm asking for is a note to the effect that a default
service provided by DHCP may not provided an untruncated set of data.

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 10 Oct 2014 14:53:26 +0200

Hello Cyrus,

Cyrus Daboo wrote:
> because there are many ways it could be done. Right now SRV seems like
> the best internet-wide solution which is why it is present. But there
> are many possible "local area" solutions: obviously DHCP is one, mDNS
> (aka Bonjour) is another. I am not sure the base spec should tackle the
> "local area" discovery topic at present, until we see that there is a
> real demand for that and what form that demand takes.

As I've tried to mention in my original email, I *don't* think discovery 
of a tzdist server via DHCP or mDNS should be dealt with by the tzdist 
specs.

It's up to the network administrators how they make a local copy of the 
official tzdist service available to the network they are responsible for.

I think mDNS is more used by plug'n'play devices in home networks. 
Otherwise anyone could just install a local PC providing (eventually 
faked) tzdist services and start to mess up all clients on the local 
network.

I'm sure most company networks would prefer publishing the IP address of 
a tzdist server via DHCP, as configured by the IT admin.

The only reason I've asked here for the DHCP option is that acceptence 
of tzdist is faster if there are reliable ways to use it, as with DHCP, 
or mDNS, or whatever, so it's great if e.g. DHCP servers and clients are 
already aware of of a an assigned option code for tzdist when the first 
tzdist servers are installed by normal admins.

Martin

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 10 Oct 2014 14:59:14 +0200

Hello Lester,

> service provided by DHCP may not provided an untruncated set of data.

I think a network administrator who *knows* what he's doing should know 
if the tzdist server he provides for his network needs to provide the 
full set of data, or only a limited set. Similarly as he needs to know 
how to install an email server meeting the requirements in the network 
he manages.

Having a note that it's possible to provide "limited" or "full" tzdist 
service is appreciated anyway, though.

Martin